From owner-freebsd-hackers Mon Jul 10 2:47:43 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail2.netcologne.de (mail2.netcologne.de [194.8.194.103]) by hub.freebsd.org (Postfix) with ESMTP id 9258E37C56C; Mon, 10 Jul 2000 02:47:38 -0700 (PDT) (envelope-from pherman@frenchfries.net) Received: from bagabeedaboo.security.at12.de (dial-195-14-233-107.netcologne.de [195.14.233.107]) by mail2.netcologne.de (8.9.3/8.9.3) with ESMTP id LAA05923; Mon, 10 Jul 2000 11:47:35 +0200 (MET DST) Received: from localhost (localhost.security.at12.de [127.0.0.1]) by bagabeedaboo.security.at12.de (8.10.2/8.10.2) with ESMTP id e6A9lOE53495; Mon, 10 Jul 2000 11:47:24 +0200 (CEST) Date: Mon, 10 Jul 2000 11:47:24 +0200 (CEST) From: Paul Herman To: Adrian Chadd Cc: core-ix@hushmail.com, freebsd-hackers@FreeBSD.ORG Subject: fork throttling (was Re: Some proposals to FreeBSD kernel) In-Reply-To: <20000710111340.C837@ywing.creative.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 10 Jul 2000, Adrian Chadd wrote: > On Mon, Jul 10, 2000, Paul Herman wrote: > > Perhaps a discussion of something like FORK_RATELIMIT along the lines > > of ICMP_BANDLIM is in order? > > why would you do that? If something wants to fork, let it fork. When > it hits the upper limit defined your resource limitations, it returns > an error. Having it slow down before erroring out and then providing > the tweaks to make this controllable sounds to me like too much added > complexity for no real gain. It's just like in my DSP programing days with limiting vs. clipping. The best solution which is most pleasing to the ears is a combination of both. (speaking of "gain" :) I envision highly loaded webservers/mailservers/etc (according to login class) slightly (usecs) slowing forking down to let other procs finish up IO or whatever it needs to do, before forking. To me, this seems much more elegant and desireable than just burping up fork errors "500 Internal Server Error", or "503 Server Unavailable". Like you say, it is probably too much added complexity, but it is being optionaly implimented as we speak in some common servers, like apache. If this behaviour is desired (and I know companies that do), it may just be a simple philosophical question of whose job it would be to throttle forks: userland or kernel. You may be right. It may be the domain of userland, but I can see advantages of the generalities of it being in the kernel. Comments? > Remember, resource limits are your friend. ;-) They are indeed. -Paul. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message