Resource beancounters

Posted Sep 16, 2006 6:50 UTC (Sat) by devx (guest, #40551)
In reply to: Resource beancounters by giraffedata
Parent article: Resource beancounters

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