LWN: Comments on "Resource beancounters"

Resource beancounters

devx — 2006-09-16T06:50:50+00:00

>> There are some concerns about how accounting for shared resources is
>> handled - does the process group which first faults in the C library get
>> charged for the whole thing, giving others a free ride?
FYI: BC accounting of user memory takes into account _fractions_ of pages. i.e. if 2 users share the same glibc and map the same page into its address space, then both will be charged 1/2 of the page.

> The few times I've tried to resolve the kernel memory accounting problem,
> I've had to quit because most of the resource is shared.
First, BC accounts only that kernel memory which is user triggerable. i.e. allocated on demand. This is required to prevent DoS. And it is not quite clear how and to whom charge all the other memory allocations, so this looks reasonably enough. e.g. whom should we charge memory allocated by interrupts?
Second, there can be different polices on how to account shared resources. Usually it is handled as "charge to the creator".

> Also, kernel code usually can't tolerate having no memory available to
> it. The only reason the kernel works at all today is that things are
> done to make it unlikely that there isn't a single page of memory
> available; but with local limits like this, it would happen a lot.
This is not 100% true.
Well, at least if we consider the objects which are allocated on user request. One of OpenVZ stress tests is to run 100 VPSs with random BC limits. These triggers different error paths in kernel and we submit patches to mainstream in case of problems. So this works quite stable and tested.

Resource beancounters

devx — 2006-09-16T06:41:23+00:00

There is a small misunderstanding. Beancounters have nothing to do with tasks directly and don't do task groupping.
Look, there are a lot of resources which can be shared: pages, IPCs, files etc. Task groupping doesn't help anyhow since the same file can belong to 2 different tasks in 2 different resource groups.
So tasks if accounted are just the same kind of abstract objects just like any other are (files, sockets, ...).

And beancounters do not track and do not have a list of the objects.
Instead, beancounters do:
- accounting
- limiting
- beancounters are referenced to _by_ all the charged objects (not otherwise) to make uncharging correct (objects freeing can be done in arbitrary context).

Resource beancounters

mtrob — 2006-09-07T00:46:25+00:00

Hmmm, I've been using this system for many years now in Linux. The product is Virtuozzo from SW Soft who recently put Open VZ out there for the kernel folks to work with. By the way, it works exceedingly well. And for a situation where you can use a common kernel virtualization (para-virtualization) it just beats the pants off VMWare and Xen.

Resource beancounters

giraffedata — 2006-08-31T22:32:46+00:00

There are some concerns about how accounting for shared resources is handled - does the process group which first faults in the C library get charged for the whole thing, giving others a free ride?

The few times I've tried to resolve the kernel memory accounting problem, I've had to quit because most of the resource is shared.

Also, kernel code usually can't tolerate having no memory available to it. The only reason the kernel works at all today is that things are done to make it unlikely that there isn't a single page of memory available; but with local limits like this, it would happen a lot.

Resource beancounters

utoddl — 2006-08-31T14:28:09+00:00

Wow. They've reinvented another flavor of process groups. Kind of like the old AFS PAG, but it tracks resource allocations instead of tracking authentication tokens. And then there's the keyring based implementation of process authentication groups that OpenAFS is moving toward and that NFSv4+ (and any other externally hosted authenticated resource) is going to need. I'm sure there are others. How many different ways of grouping processes do we need, and does some of this code overlap?