From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 16174 invoked from network); 14 Jun 2021 17:24:53 -0000 Received: from 1ess.inri.net (216.126.196.35) by inbox.vuxu.org with ESMTPUTF8; 14 Jun 2021 17:24:53 -0000 Received: from duke.felloff.net ([216.126.196.34]) by 1ess; Mon Jun 14 13:18:27 -0400 2021 Message-ID: <7113E70C01D7084972602F13901ED0EF@felloff.net> Date: Mon, 14 Jun 2021 19:18:16 +0200 From: cinap_lenrek@felloff.net To: 9front@9front.org In-Reply-To: <3B7CD4D57FAF1705F3A5E6363CAADE67@eigenstate.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: markup CSS firewall Subject: Re: [9front] [PATCH] kernel: make conf.nproc configurable. all kernels now default to 100 + ((conf.npage*BY2PG)/MB)*5 Reply-To: 9front@9front.org Precedence: bulk also just increasing nproc will have performance degradation in some places. the kernel in some places will just iterate over all process slots for some queries, like sending to a note group or finding the processes that use a segment. if that stucrure could be more dynamic we might not even need to have such low nproc defaults. but it is here because keeping it small keeps these operations fast. there are also limiting factors like that we need to allocate KSTACK bytes of memory for each process. and buffers when they do i/o... which might be more limited by kernel KZERO address window. -- cinap