linux-kernel - 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] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 09 Aug 2006 00:19:41 +1000
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	Martin Bligh <mbligh@...igh.org>
CC:	rohitseth@...gle.com, Dave Hansen <haveblue@...ibm.com>,
	Kirill Korotaev <dev@...ru>, 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: memory resource accounting (was Re: [RFC, PATCH 0/5] Going forward
 with Resource Management - A	cpu controller)

Martin Bligh wrote:
> Rohit Seth wrote:
> 

Hi guys, let me make a fool of myself and jump in this thread...

>> I think there is lot of simplicity and value add by charging one
>> container (even unfairly) for one resource completely.  This puts the
>> onus on system admin to set up the containers appropriately.
> 
> 
> It also saves you from maintaining huge lists against each page.
> 
> Worse case, you want to bill everyone who opens that address_space
> equally. But the semantics on exit still suck.
> 
> What was Alan's quote again? "unfair, unreliable, inefficient ...
> pick at least one out of the three". or something like that.

What's the sucking semantics on exit? I haven't looked much at the
existing memory controllers going around, but the implementation I
imagine looks something like this (I think it is conceptually similar
to the basic beancounters idea):

- anyone who allocates a page for anything gets charged for that page.
   Except interrupt/softirq context. Could we ignore these for the moment?

   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.

- each struct page has a backpointer to its billed container. At the mm
   summit Linus said he didn't want back pointers, but I clarified with him
   and he isn't against them if they are easily configured out when not using
   memory controllers.

- memory accounting containers are in a hierarchy. If you want to destroy a
   container but it still has billed memory outstanding, that gets charged
   back to the parent. The data structure itself obviously still needs to
   stay around, to keep the backpointers from going stale... but that could
   be as little as a word or two in size.

The reason I like this way of accounting is that it can be done with a couple
of hooks into page_alloc.c and an ifdef in mm.h, and that is the extent of
the impact on core mm/ so I'd be against anything more intrusive unless this
really doesn't work.

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 
-
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/