From: Balbir Singh <balbir@in.ibm.com>
To: Kirill Korotaev <dev@sw.ru>
Cc: Andrew Morton <akpm@osdl.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
Christoph Hellwig <hch@infradead.org>,
Pavel Emelianov <xemul@openvz.org>, Andrey Savochkin <saw@sw.ru>,
devel@openvz.org, Rik van Riel <riel@redhat.com>,
Andi Kleen <ak@suse.de>, Greg KH <greg@kroah.com>,
Oleg Nesterov <oleg@tv-sign.ru>,
Matt Helsley <matthltc@us.ibm.com>,
Rohit Seth <rohitseth@google.com>,
Chandra Seetharaman <sekharan@us.ibm.com>
Subject: Re: [PATCH] BC: resource beancounters (v2)
Date: Tue, 29 Aug 2006 22:38:45 +0530 [thread overview]
Message-ID: <44F4749D.9050403@in.ibm.com> (raw)
In-Reply-To: <44F45ED7.3050708@sw.ru>
Kirill Korotaev wrote:
>>> ------------- cut ----------------
>>> The task of limiting a container to 4.5GB of memory bottles down to the
>>> question: what to do when the container starts to use more than assigned
>>> 4.5GB of memory?
>>>
>>> At this moment there are only 3 viable alternatives.
>>>
>>> A) Have separate memory management for each container,
>>> with separate buddy allocator, lru lists, page replacement mechanism.
>>> That implies a considerable overhead, and the main challenge there
>>> is sharing of pages between these separate memory managers.
>>>
>>> B) Return errors on extension of mappings, but not on page faults, where
>>> memory is actually consumed.
>>> In this case it makes sense to take into account not only the size
>>> of used
>>> memory, but the size of created mappings as well.
>>> This is approximately what "privvmpages" accounting/limiting
>>> provides in
>>> UBC.
>>>
>>> C) Rely on OOM killer.
>>> This is a fall-back method in UBC, for the case "privvmpages" limits
>>> still leave the possibility to overload the system.
>>>
>>
>>
>> D) Virtual scan of mm's in the over-limit container
>>
>> E) Modify existing physical scanner to be able to skip pages which
>> belong to not-over-limit containers.
>>
>> F) Something else ;)
> We fully agree that other possible algorithms can and should exist.
> My idea only is that any of them would need accounting anyway
> (which is the most part of beancounters).
> Throtling, modified scanners etc. can be implemented as a separate
> BC parameters. Thus, an administrator will be able to select
> which policy should be applied to the container which is near its limit.
>
> So the patches I'm trying to send are a step-by-step accounting of all
> the resources and their simple limitations. More comprehensive limitation
> policy will be built on top of it later.
>
One of the issues I see is that bean counters are not very flexible. Tasks
cannot change bean counters dynamically after fork()/exec() that is - can they?
> BTW, UBC page beancounters allow to distinguish pages used by only one
> container and pages which are shared. So scanner can try to reclaim
> container private pages first, thus not influencing other containers.
>
But can you select the specific container for which we intend to scan pages?
> Thanks,
> Kirill
>
--
Thanks,
Balbir Singh,
Linux Technology Center,
IBM Software Labs
next prev parent reply other threads:[~2006-08-29 17:08 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-23 10:46 Kirill Korotaev
2006-08-23 11:01 ` [PATCH 1/6] BC: kconfig Kirill Korotaev
2006-08-23 13:04 ` Alexey Dobriyan
2006-08-23 22:04 ` [Devel] " Dave Hansen
2006-08-23 22:13 ` Matt Helsley
2006-08-23 22:32 ` Randy.Dunlap
2006-08-23 22:27 ` Matt Helsley
2006-08-25 11:30 ` Kirill Korotaev
2006-08-25 11:34 ` Kirill Korotaev
2006-08-24 0:23 ` Chandra Seetharaman
2006-08-24 11:47 ` [ckrm-tech] " Kirill Korotaev
2006-08-24 22:23 ` Matt Helsley
2006-08-23 11:03 ` [PATCH 2/6] BC: beancounters core (API) Kirill Korotaev
2006-08-23 11:37 ` Andi Kleen
2006-08-23 13:27 ` Kirill Korotaev
2006-08-23 13:48 ` Andi Kleen
2006-08-23 13:30 ` Alexey Dobriyan
2006-08-23 13:49 ` Kirill Korotaev
2006-08-23 13:53 ` Alexey Dobriyan
2006-08-23 22:05 ` Matt Helsley
2006-08-23 16:42 ` Andrew Morton
2006-08-24 12:06 ` Kirill Korotaev
2006-08-24 15:00 ` Andrew Morton
2006-08-25 10:53 ` Kirill Korotaev
2006-08-24 14:13 ` Oleg Nesterov
2006-08-24 21:33 ` Oleg Nesterov
2006-08-23 11:05 ` [PATCH 3/6] BC: context inheriting and changing Kirill Korotaev
2006-08-23 11:06 ` [PATCH 4/6] BC: user interface (syscalls) Kirill Korotaev
2006-08-23 13:41 ` Alexey Dobriyan
2006-08-23 13:43 ` Kirill Korotaev
2006-08-23 16:50 ` Andrew Morton
2006-08-23 17:29 ` Alan Cox
2006-08-24 4:35 ` Andrew Morton
2006-08-24 11:04 ` Alan Cox
2006-08-24 13:08 ` Alexey Dobriyan
2006-08-25 10:56 ` Kirill Korotaev
2006-08-24 0:30 ` Chandra Seetharaman
2006-08-23 11:06 ` [PATCH 5/6] BC: kernel memory accounting (core) Kirill Korotaev
2006-08-24 0:36 ` Chandra Seetharaman
2006-08-24 21:23 ` Oleg Nesterov
2006-08-25 10:09 ` Kirill Korotaev
2006-08-23 11:08 ` [PATCH 6/6] BC: kernel memory accounting (marks) Kirill Korotaev
2006-08-23 18:30 ` [Devel] " Dave Hansen
2006-08-29 9:52 ` Kirill Korotaev
2006-08-29 15:48 ` Dave Hansen
2006-08-29 15:56 ` Kirill Korotaev
2006-08-23 23:03 ` Dave Hansen
2006-08-24 9:30 ` Geert Uytterhoeven
2006-08-24 15:52 ` Dave Hansen
2006-08-29 14:37 ` Kirill Korotaev
2006-08-23 17:05 ` [PATCH] BC: resource beancounters (v2) Andrew Morton
2006-08-24 0:17 ` Chandra Seetharaman
2006-08-25 11:49 ` Kirill Korotaev
2006-08-25 14:30 ` Andrew Morton
2006-08-25 14:48 ` Andi Kleen
2006-08-28 8:28 ` Kirill Korotaev
2006-08-25 15:14 ` Nick Piggin
2006-08-25 15:57 ` Alan Cox
2006-08-26 3:55 ` Nick Piggin
2006-08-25 16:30 ` Andrey Savochkin
2006-08-25 17:50 ` Andrew Morton
2006-08-25 19:00 ` Chandra Seetharaman
2006-08-26 2:15 ` Rohit Seth
2006-08-26 16:37 ` Alan Cox
2006-08-28 16:48 ` Rohit Seth
2006-08-28 17:41 ` [Devel] " Kir Kolyshkin
2006-08-28 22:28 ` Rohit Seth
2006-08-29 10:15 ` Alan Cox
2006-08-29 17:30 ` Rohit Seth
2006-08-29 19:06 ` Alan Cox
2006-08-29 19:15 ` Rohit Seth
2006-08-29 15:35 ` [PATCH] " Kirill Korotaev
2006-08-29 17:08 ` Balbir Singh [this message]
2006-08-23 21:00 ` Cedric Le Goater
2006-08-24 5:52 ` Jan Engelhardt
2006-08-24 10:59 ` Alan Cox
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=44F4749D.9050403@in.ibm.com \
--to=balbir@in.ibm.com \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=dev@sw.ru \
--cc=devel@openvz.org \
--cc=greg@kroah.com \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matthltc@us.ibm.com \
--cc=oleg@tv-sign.ru \
--cc=riel@redhat.com \
--cc=rohitseth@google.com \
--cc=saw@sw.ru \
--cc=sekharan@us.ibm.com \
--cc=xemul@openvz.org \
/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
Powered by JetHome