> Ouch. Now every time I want to, say, perform a page fault, the kernel
> has to check the process's resident set size against 7 separate limits?
> And update those 7 limits too, causing 7 separate cache misses if
> another CPU is hosting another thread of the same process and wants to
> do the same thing?
>
You only compair aginst the minimum of the collection, computed when a
job/session is started. All processes created afterwards deduct from the
job/session accounting structure which would have only one value per
resource.
> That is way overkill, I'm afraid. Per-process (ie. per-thread-group)
> and per-user is a much more manageable set and entirely covers the main
> reasons why people want this: protection against a single runaway
> process, and protection against a user DoS attack.
>
Doesn't really protect against a DoS attack. The system manager can still
oversubscribe the available resources (just as disk quotas frequently are).
> > Is this a bit of an overkill?
>
> No, it's a lot of an overkill. :)
>
Actually, only if a primitive implementation is done. What is actually used
in other systems:
1. User logs in
job session id is created with:
minimum of per process, per group(account), per thread, per user,
per system is loaded into a prototype accounting structure.
If the job initialization procedure determines that there is not enough
resources to start the job, then a "insufficient resources ..." message
is given to the user, and the login/cron/batch job is terminated, or not
started at all (batch queueing systems tend to do this).
2. Process creation subtracts from the session limits listed in the accounting
structure.
3. resources are controled by checking aginst the session accounting
structure. Only one comparison per resource.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/