Re: Process Aggregates: module based support for jobs

From: Andrey Savochkin (
Date: Sat Jun 17 2000 - 09:59:20 EST


On Fri, Jun 16, 2000 at 10:42:05PM +0200, Andi Kleen wrote:
> On Fri, Jun 16, 2000 at 03:21:19PM -0500, Sam Watters wrote:
> > I agree, providing resource limits will require additional hooks beyond fork and
> > exit. Our initial goal was to provide a job container in support of job
> > accounting. The next step is to develop resource limits.
> >
> > We have held off on the resource limits because that tends to be a problem area
> > (as we have experienced when developing job based resource limits on IRIX). I
> > foresee the following problems that must be addressed as job based resource
> > limits are implemented.
> >
> > 1. How to handle the counting of shared memory pages. This has been an
> > extremely difficult problem on IRIX to get right - in fact, it is still not done
> > correctly.
> All VM pages would be probably left out in the first implementation;
> it requires lots of infrastructure in the VM that just isn't there yet. They
> aren't that critical because they can be swapped out anyways. I'm looking
> primarily for a solution of limiting pinned down buffers (like network buffers)
> per user/group/job/login in.

It was resource limiting rather than just accounting that was the goal for
user beancounter patch. And the first and most important part was exactly
the accounting and limiting the amount unswappable memory allocated by the
kernel to serve user's needs.

The most important component which is already implemented in user beancounter
patch is accounting for pages allocated to be used as page directories for
virtual to physical address mappings. Socket buffer accounting is the first
thing in my current todo list.

Certainly, the patch touches critical parts of the kernel, and, thus, I tried
to do it as much straightforward and efficient as possible.

I recently announced to linux-kernel that user beancounter patch is
resurrected. Here is 2.4.0-test1 port of the old patch:
(oh dear, how quickly time passes!)

I've also extracted bits of information describing the design and current
status of the patch and put it as a separate web page:

Best regards

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

This archive was generated by hypermail 2b29 : Fri Jun 23 2000 - 21:00:14 EST