Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 10 Jul 2000 11:47:24 +0200 (CEST)
From:      Paul Herman <pherman@frenchfries.net>
To:        Adrian Chadd <adrian@FreeBSD.ORG>
Cc:        core-ix@hushmail.com, freebsd-hackers@FreeBSD.ORG
Subject:   fork throttling (was Re: Some proposals to FreeBSD kernel)
Message-ID:  <Pine.BSF.4.21.0007101114110.265-100000@bagabeedaboo.security.at12.de>
In-Reply-To: <20000710111340.C837@ywing.creative.net.au>

next in thread | previous in thread | raw e-mail | index | archive | help

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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0007101114110.265-100000>