linux-kernel - Re: memory resource accounting (was Re: [RFC, PATCH 0/5] Going forward with Resource Management

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <44D9E676.6000707@sw.ru>
Date:	Wed, 09 Aug 2006 17:43:18 +0400
From:	Kirill Korotaev <dev@...ru>
To:	Nick Piggin <nickpiggin@...oo.com.au>
CC:	Dave Hansen <haveblue@...ibm.com>,
	Martin Bligh <mbligh@...igh.org>, rohitseth@...gle.com,
	vatsa@...ibm.com, Alan Cox <alan@...rguk.ukuu.org.uk>,
	Andrew Morton <akpm@...l.org>, mingo@...e.hu, sam@...ain.net,
	linux-kernel@...r.kernel.org, dev@...nvz.org, efault@....de,
	balbir@...ibm.com, sekharan@...ibm.com, nagar@...son.ibm.com,
	pj@....com, Andrey Savochkin <saw@...ru>
Subject: Re: memory resource accounting (was Re: [RFC, PATCH 0/5] Going	forward
 with Resource Management - A	cpu controller)

> 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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/