Re: memory resource accounting (was Re: [RFC, PATCH 0/5] Going forward with Resource Management - A cpu controller)

[Nick Piggin <nickpiggin@yahoo.com.au>]

Dave Hansen wrote:
> On Wed, 2006-08-09 at 00:19 +1000, Nick Piggin wrote:
> 
>>   This does give you kernel (slab, pagetable, etc) allocations as well as
>>   userspace. I don't like the idea of doing controllers for inode cache
>>   and controllers for dentry cache, etc, etc, ad infinitum.
> 
> 
> Those two might not be such a bad idea.  Of the slab in my system, 90%
> is reliably from those two slabs alone.  Now, a controller for the
> 'Acpi-Operand' slab might be going too far. ;)
> 
> Certainly something we should at least consider down the road.

But if you have a unified struct page accounting, you don't need that.
You don't need struct radix_tree_node accounting, you don't need buffer_head
accounting, pagetable page accounting, vm_area_struct accounting, task_struct
accounting, etc etc in order to do your memory accounting if what you just
want to know is "who allocated what".

And remember that if you have one container going crazy with inode/dentry
cache, it will get hit by its resource limit and end up having to reclaim
them or go OOM.

Now you *may* want to split the actual accounting into kernel and user parts
if you're worried about obscure corner cases in kernel memory accounting. But
this would basically come for free when you have the GFP_EASYRECLAIM thingy
(at any rate, it is quite unintrusive).


Basically, what I have been hearing is that people want to be able to
surgically isolate the memory allocation of one container from that of
another. IMO this is simply infeasible (and exploit prone) to do it on a
per-kernel-object basis.

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com