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

Message-ID: <20060809105603.A26520@castle.nmd.msu.ru>
Date:	Wed, 9 Aug 2006 10:56:03 +0400
From:	Andrey Savochkin <saw@...ru>
To:	Nick Piggin <nickpiggin@...oo.com.au>
Cc:	Martin Bligh <mbligh@...igh.org>, 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
Subject: Re: memory resource accounting (was Re: [RFC, PATCH 0/5] Going forward with Resource Management - A	cpu controller)

Nick,

On Wed, Aug 09, 2006 at 12:19:41AM +1000, Nick Piggin wrote:
[snip]
> 
> 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):

What you suggests implies an over-simplification of how memory is used in the
system, and doesn't take into account sharing and caching.

Namely:

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

So, are you suggesting that the user (or container) that initially looked up
some directory /var/dir, will stay billed for this memory until
 - all users of all subdirectories /var/dir/a/b/c/d/e/f/g/h/i etc.
   are gone, and
 - dentry cache has been shrunk because of memory pressure?

It is unfair.
But more than that:
one of the goals of resource accounting and restrictions is to give users the
idea of how much resources they are using.  Then, when they start to use more
than their allotment, they should be given the opportunity to consider what
they are doing and reduce resource usage.

In my opinion, to make resource accounting useful, serious efforts should
be made not to bill anyone for resources which he isn't really using and has
no control over releasing them.

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

The same thing: if one user mapped and then released some pages from a shared
library, should he be billed for these pages until all other users unmapped
this library, and page cache has been shrunk?

Best regards
		Andrey
-
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/