On Thu, Dec 05, 2002 at 02:50:24PM -0500, Gary Thorpe wrote:

> Would lowering the process priority of the offending process
> temporarily be a good alternative to sleeping or is it all just a bad
> idea? Would cpu hogs get lowered priorities anyway, making this
> unneeded?

Some seem to reply to this that it isn't consistant with traditional
UNIX behavior, others that the kernel already has all necessary
restrictions implemented...

I therefore seem to see the same problem, and as well suggest a
kernel solution (not a hack). This .5s sleep appears like an
incomplete hack to cope with a larger problem at hand which
hasn't been dealt with properly at the scheduler level.

NetBSD is a modern OS afterall, and is often one of the first to
generally implement new solutions in testbeds, although providing
"solutions, not hack" and remaining proud if it. Of course it is
also an old operating system which at the same time strives to
remain standards-compliant.

A solution directed towards some kernel scheduler ameliorations
for general system responsiveness tends to agree with both
strong sides of NetBSD, IMHO. And we have people on the project
who actually can make this happen.

It is important that processes which are expected to run for
long periods and require alot of CPU resources need to be
treated with lower priority by the scheduler for the rest of
the userspace system to remain very responsive at all times.
This not only solves most of the fork(2) bomb issues of our
thread, but also permits to cope with other type of resource
attack programs. Moreover, it also helps in the case of bugs
or administrator ignorance which result in such loops.

Obviously, those processes would still be given any CPU rounds
they need and expect to have, but would starve them as necessary
when other processes need to be launched or perform critical
tasks. And we have such a working priority system. It just could
also be taken advantage at directly at the kernel level too.
This wouldn't amount to incredibly more process accounting
neither... Trivial algorithms could be used to alter the
priority as required.

One has to know that a process can detach as a new process group,
and some consideration should be taken so that they still somewhat
remain tied to their master processes, accordingly.

As per user resources it indeed would get more complicated if
the kernel also had to account in this case, but the work at
scheduler level for internal process renicing and process group
tracking should solve most issues IMHO.

Moreover, userspace APIs would not need any change to make
this possible. The UNIX environment would still appear as such.

I would like to know clearly, what are the drawbacks in this
exactly, except perhaps the time and work required to make it
possible? Wouldn't this more be in the range of "solution,
not hacks", which I am still quoting from the site? The
scheduler activations are less trivial to implement and become
a reality...

IMHO, FreeBSD has made other bad choices too, than implementing
this .5s kludge, it should not particularly be a good example
to follow in all directions neither... Although I wouldn't
object to the fact that some of the ideas implemented on it
are great still.

Matt