Re: Resource Limits Architecture

Oliver Xymoron (oxymoron@waste.org)
Fri, 17 Sep 1999 10:48:31 -0500 (CDT)


On Fri, 17 Sep 1999, Stephen C. Tweedie wrote:

> > Per-System : Limits which are placed on all processes
> > Per-Group : Limits which are placed on all processes from a group id
> > Per-User : Limits which are placed on all processes from a user id
> > Per-Process Group : Limits which are placed on a group of processes (shared)
> > Per-Process : Limits which are placed on a process
> > Per-Thread Group : Limits which are placed on a group of threads (shared)
> > Per-Thread : Limits which are placed on a thread
>
> 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?
>
> 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.

Seems to me this is an identical problem to the IP firewall/ forward/
accounting/ masquerade thing. We just put a callback hook at the relevant
places. If the user compiled without beancounting, the hook gets left out.
If the user hasn't installed any policy, the hook call gets skipped.

The hook can be setup to be code identical to the traditional ulimit stuff
or a flexible netfilter-style chain (with ulimit emulation of course). The
user can then build up a policy chain including forwarding to userspace or
passing it through special modules. Policy options could including
killing, suspending, renicing, etc. This also addresses the OOM problem -
the user can now setup a policy not to kill X or init, for instance.

Quota, of course, is the same problem set.

--
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.." 

- 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/