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
<[EMAIL PROTECTED]> rest of the evening. Set a man on fire and
he's warm for the rest of his life.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
