On Fri, 6 Dec 2002, Jaromir Dolecek wrote:

# The thttpd (IMO broken) behaviour is exactly why I earlier said it
# wouldn't help to check rate with which fork() is called by process,
# since even 'innocent' daemons would trigger the rate check and be
# put to sleep anyway.

# Perhaps there is some disagreement on the purpose of user/system
# limits.

Perhaps instead of looking at apps which don't have the sense to play nice
and then pointing to the kernel for responsibility, perhaps it's time to
fix the apps.

Idea, though:  How about a one-off 'pseudo-slot' per process (read: bit
flag) which says 'this process wanted to create more processes after it
hit its/the limit; begin enforcing delays on process creation', with a
backoff somewhere which will clear said flag after a suitable amount of
time?

# IMHO the limits are there to ensure fair resource usage among users.
# The limits should be set in a way that the user (or daemon) never
# really reaches it during normal operation, but so that it would
# provide safety net should things unexpectedly (due to software bug,
# malicious user or attack) start behaving oddly and tried to consume
# unexpected amount of resources.

This seems reasonable...

# IMHO the thttpd behaviour is broken. It should really have some
# limit of 'maximum or running spawned children', rather than spawning
# unlimited number of childs to serve any incoming requests.

"Fix the app, or don't port it."

On another tangent:  Someone mentioned a process getting reniced after
consuming a significant amount of CPU time.   This only occurs for procs
which maintain a nice value of 0; if a proc gets reniced to 1 (well, 21
(which impact is minimal)), the CPU time nice self-adjust never happens.
So you can see where that goes in the face of a tight-spin process.

[and yet another tangent, something I've thought on for years:  I note
 that there is no way to re-renice a process once the priority gets
 lowered.  Has it occurred to anyone else that it might be useful to have
 a saved p_nice (p_hnice) to which the original nice value gets saved,
 which only gets adjusted when the superuser calls setpriority(2), but could
 otherwise allow a process to readjust its nice value?  Or is this too open
 to DoS?]

				--*greywolf;
--
NetBSD: No Sh;t!