From: Andrey Savochkin <saw@sw.ru>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Martin Bligh <mbligh@mbligh.org>,
rohitseth@google.com, Dave Hansen <haveblue@us.ibm.com>,
Kirill Korotaev <dev@sw.ru>,
vatsa@in.ibm.com, Alan Cox <alan@lxorguk.ukuu.org.uk>,
Andrew Morton <akpm@osdl.org>,
mingo@elte.hu, sam@vilain.net, linux-kernel@vger.kernel.org,
dev@openvz.org, efault@gmx.de, balbir@in.ibm.com,
sekharan@us.ibm.com, nagar@watson.ibm.com, pj@sgi.com
Subject: Re: memory resource accounting (was Re: [RFC, PATCH 0/5] Going forward with Resource Management - A cpu controller)
Date: Wed, 9 Aug 2006 10:56:03 +0400 [thread overview]
Message-ID: <20060809105603.A26520@castle.nmd.msu.ru> (raw)
In-Reply-To: <44D89D7D.8040006@yahoo.com.au>; from "Nick Piggin" on Wed, Aug 09, 2006 at 12:19:41AM
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
next prev parent reply other threads:[~2006-08-09 6:56 UTC|newest]
Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-04 5:07 [RFC, PATCH 0/5] Going forward with Resource Management - A cpu controller Srivatsa Vaddagiri
2006-08-04 5:09 ` [ RFC, PATCH 1/5 ] CPU controller - base changes Srivatsa Vaddagiri
2006-08-04 7:35 ` Andrew Morton
2006-08-04 11:18 ` Srivatsa Vaddagiri
2006-08-04 14:34 ` Kirill Korotaev
2006-08-04 14:50 ` Balbir Singh
2006-08-04 14:51 ` Srivatsa Vaddagiri
2006-08-04 5:10 ` [ RFC, PATCH 2/5 ] CPU controller - Define group operations Srivatsa Vaddagiri
2006-08-04 23:10 ` Jiri Slaby
2006-08-04 5:11 ` [ RFC, PATCH 3/5 ] CPU controller - deal with movement of tasks Srivatsa Vaddagiri
2006-08-04 5:12 ` [ RFC, PATCH 4/5 ] CPU controller - deal with dont care groups Srivatsa Vaddagiri
2006-08-04 5:13 ` [ RFC, PATCH 5/5 ] CPU controller - interface with cpusets Srivatsa Vaddagiri
2006-08-04 5:36 ` [RFC, PATCH 0/5] Going forward with Resource Management - A cpu controller Andrew Morton
2006-08-04 5:42 ` Andrew Morton
2006-08-04 9:49 ` Alan Cox
2006-08-04 11:41 ` Srivatsa Vaddagiri
2006-08-04 14:51 ` Kirill Korotaev
2006-08-04 15:31 ` Srivatsa Vaddagiri
2006-08-04 16:03 ` Kirill Korotaev
2006-08-04 17:02 ` [ProbableSpam] " Shailabh Nagar
2006-08-04 18:27 ` Rohit Seth
2006-08-04 19:11 ` Shailabh Nagar
2006-08-04 19:24 ` Rohit Seth
2006-08-07 7:19 ` Kirill Korotaev
2006-08-07 17:14 ` Rohit Seth
2006-08-08 7:17 ` Kirill Korotaev
2006-08-08 17:16 ` Rohit Seth
2006-08-04 17:50 ` Martin Bligh
2006-08-07 7:25 ` Kirill Korotaev
2006-08-07 14:34 ` Martin J. Bligh
2006-08-07 16:33 ` Kirill Korotaev
2006-08-07 18:31 ` Rohit Seth
2006-08-07 18:43 ` Dave Hansen
2006-08-07 19:00 ` Rohit Seth
2006-08-07 19:46 ` Martin Bligh
2006-08-08 14:19 ` memory resource accounting (was Re: [RFC, PATCH 0/5] Going forward with Resource Management - A cpu controller) Nick Piggin
2006-08-08 14:57 ` Dave Hansen
2006-08-08 15:22 ` Nick Piggin
2006-08-09 13:43 ` Kirill Korotaev
2006-08-08 17:08 ` Martin Bligh
2006-08-09 1:54 ` Nick Piggin
2006-08-08 17:34 ` Rohit Seth
2006-08-09 4:33 ` Andi Kleen
2006-08-09 6:00 ` Magnus Damm
2006-08-09 6:06 ` Andi Kleen
2006-08-09 6:56 ` Andrey Savochkin [this message]
2006-08-08 7:19 ` [RFC, PATCH 0/5] Going forward with Resource Management - A cpu controller Kirill Korotaev
2006-08-04 16:16 ` Kirill Korotaev
2006-08-04 16:49 ` [ProbableSpam] " Shailabh Nagar
2006-08-04 17:03 ` Dipankar Sarma
2006-08-04 18:17 ` Shailabh Nagar
2006-08-07 7:23 ` Kirill Korotaev
2006-08-04 14:57 ` Kirill Korotaev
2006-08-04 5:58 ` Paul Jackson
2006-08-04 6:02 ` Paul Jackson
2006-08-04 6:16 ` Paul Jackson
2006-08-04 6:20 ` Dipankar Sarma
2006-08-04 6:31 ` Paul Jackson
2006-08-04 6:37 ` Dipankar Sarma
2006-08-04 6:49 ` Andrew Morton
2006-08-04 6:45 ` Andrew Morton
2006-08-04 7:10 ` Dipankar Sarma
2006-08-04 7:24 ` Andrew Morton
2006-08-04 19:10 ` Chandra Seetharaman
2006-08-04 6:56 ` Srivatsa Vaddagiri
2006-08-04 7:13 ` Andrew Morton
2006-08-04 11:16 ` Srivatsa Vaddagiri
2006-08-04 18:51 ` Andrew Morton
2006-08-04 14:20 ` Kirill Korotaev
2006-08-04 14:35 ` Christoph Hellwig
2006-08-04 15:29 ` [ProbableSpam] " Shailabh Nagar
2006-08-07 7:29 ` Kirill Korotaev
2006-08-07 9:30 ` Paul Jackson
2006-08-07 15:58 ` Chandra Seetharaman
2006-08-07 16:10 ` Kirill Korotaev
2006-08-07 17:15 ` Paul Jackson
2006-08-07 18:19 ` Rohit Seth
2006-08-05 3:30 ` Nick Piggin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060809105603.A26520@castle.nmd.msu.ru \
--to=saw@sw.ru \
--cc=akpm@osdl.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=balbir@in.ibm.com \
--cc=dev@openvz.org \
--cc=dev@sw.ru \
--cc=efault@gmx.de \
--cc=haveblue@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mbligh@mbligh.org \
--cc=mingo@elte.hu \
--cc=nagar@watson.ibm.com \
--cc=nickpiggin@yahoo.com.au \
--cc=pj@sgi.com \
--cc=rohitseth@google.com \
--cc=sam@vilain.net \
--cc=sekharan@us.ibm.com \
--cc=vatsa@in.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®