Re: Resource Limits Architecture

Jesse Pollard (pollard@tomcat.admin.navo.hpc.mil)
Sun, 19 Sep 1999 12:15:10 -0500 (CDT)


>From saw@msu.ru Sat Sep 18 01:24:09 1999
>On Fri, Sep 17, 1999 at 10:26:32AM -0500, Jesse Pollard wrote:
>> From: "Stephen C. Tweedie" <sct@redhat.com>
>> > 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.
>
>You're missing the point.
>
>You need to check if per-user resource limits allow an extra user's page at
>this moment (not at the moment of session starting). And you need to update
>this per-user account. _And_ you need to check if per-process group limits
>allow an extra page at _this_ moment taking into account how much other
>processes consume right now. And so on...
>

You compute the minimum at session/job startup, not try to preallocate.
All processes started after that deduct from the session/job accounting record.
This way the job accounting record always has the current maximum limits for
all processes started by the job. Any other optimizations are left up to the
implmementation.

Only a single compair per resource should be needed. Now, if the system is
oversubscribed, there may need to be more.. but only (political) management
can force oversubscription. And if they do, then they deserve the system
hang/crash that may occur. BTW, that really does happen. We had a Cray
system that had swap oversubscribed - everytime someone filled the actual swap
space the system would hang. And it kept happening until the oversubscription
was eliminated. This problem also occurs on SGI Origin systems that are
oversubscribed, but there the processes get killed - even system processes
like inetd, getty, init.. anything that attempts to use virtual memory.

>So much limits is really an unnecessary overhead.

It is "unnecessary" only if you do not have to justify the next upgrade
of a 100 system beowulf cluster (with possibly 200 CPUs, and 100 GB of
memory), or justify a larger allocation of an existing system.

Unnecessary is relative to the size of the system.

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