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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 

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

Sorry, are you suggesting to use page accounting for slab objects?
You mean, that if we can account page fractions then we can charge
part of slab page to object owners?
If this is correct, then I think it is ineffecient.
In our current implementation page beancounters can charge
only equal fraction of page to each owner, so it is not suitable for slabs.
Moreoever, it is easier to do correct accounting from the slab allocator
itself and with much less overhead.


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.

In order to decide which of the containers is crazy you need
to account correctly the amount of _pinned_ dcache memory.
And even to select correct container for OOM you need to have a corect accounting
of _pinned_ dcache.
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.

We have the following scheme:
cache which should be charged are marked as SLAB_UBC. the same for particular allocations,
we have a GFP_UBC flag specifing that the allocation should be charged to
the owner. Does it look good for you?
I will post kernel memory accounting patches soon here.

Thanks,
Kirill
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux