Date: Mon, 10 Jul 2000 12:43:55 +0200 From: Adrian Chadd <adrian@FreeBSD.ORG> To: Paul Herman <pherman@frenchfries.net> Cc: Adrian Chadd <adrian@FreeBSD.ORG>, core-ix@hushmail.com, freebsd-hackers@FreeBSD.ORG Subject: Re: fork throttling (was Re: Some proposals to FreeBSD kernel) Message-ID: <20000710124355.D837@ywing.creative.net.au> In-Reply-To: <Pine.BSF.4.21.0007101114110.265-100000@bagabeedaboo.security.at12.de>; from pherman@frenchfries.net on Mon, Jul 10, 2000 at 11:47:24AM %2B0200 References: <20000710111340.C837@ywing.creative.net.au> <Pine.BSF.4.21.0007101114110.265-100000@bagabeedaboo.security.at12.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jul 10, 2000, Paul Herman wrote: > > 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. One could quite validly argue that its a design fault with apache more than it is a problem the kernel could "solve". If the kernel wasn't scheduling correctly then I'd say "Its a kernel problem", but if the process is abusing forks or accept queues then I would be quite happy to say "its a userland problem". > 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? Well, IMHO I think something like this implemented in the kernel for the reasons given above would let people write bad code. Should the kernel need massaging because people write bad code? The kernel is there to provide and schedule services for userland processes. Now, granted, there are a few things going into -current as of late which could also be attacked as letting people "write bad code", but those changes have been thoroughly discussed by many people and people are generally (hah!) agreed that they augment userland services more than replace them. > > Remember, resource limits are your friend. ;-) > > They are indeed. Don't get me wrong, I think the idea of introducing a sleep before each fork could be useful for resource limitations, but I also think that this can be implemented as an application sees fit. Otherwise, you'd have to make it a per-process tunable and add extra complexity for everything when only a few things would actually benefit from its use. Adrian -- Adrian Chadd Build a man a fire, and he's warm for the <adrian@FreeBSD.org> rest of the evening. Set a man on fire and he's warm for the rest of his life. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000710124355.D837>