From: Balbir Singh <balbir@in.ibm.com>
To: Pavel Emelianov <xemul@openvz.org>
Cc: Linux MM <linux-mm@kvack.org>,
dev@openvz.org, ckrm-tech@lists.sourceforge.net,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
haveblue@us.ibm.com, rohitseth@google.com
Subject: Re: [RFC][PATCH 8/8] RSS controller support reclamation
Date: Fri, 10 Nov 2006 18:12:53 +0530 [thread overview]
Message-ID: <455473CD.10609@in.ibm.com> (raw)
In-Reply-To: <4554466F.8010602@openvz.org>
Pavel Emelianov wrote:
> Balbir Singh wrote:
>
> [snip]
>
>>> And what about a hard limit - how would you fail in page fault in
>>> case of limit hit? SIGKILL/SEGV is not an option - in this case we
>>> should run synchronous reclamation. This is done in beancounter
>>> patches v6 we've sent recently.
>>>
>> I thought about running synchronous reclamation, but then did not follow
>> that approach, I was not sure if calling the reclaim routines from the
>> page fault context is a good thing to do. It's worth trying out, since
>
> Each page fault potentially calls reclamation by allocating
> required page with __GFP_IO | __GFP_FS bits set. Synchronous
> reclamation in page fault is really normal.
True. I don't know what I was thinking, thanks for making me think
straight.
>
> [snip]
>
>>> Please correct me if I'm wrong, but does this reclamation work like
>>> "run over all the zones' lists searching for page whose controller
>>> is sc->container" ?
>>>
>> Yeah, that's correct. The code can also reclaim memory from all over-the-limit
>
> OK. What if I have a container with 100 pages limit in a 4Gb
> (~ million of pages) machine and this group starts reclaiming
> its pages. In case this group uses its pages heavily they will
> be at the beginning of an LRU list and reclamation code would
> have to scan through all (million) pages before it finds proper
> ones. This is not optimal!
>
Yes, thats possible. The trade off is between
The cost associated with traversing that list while reclaiming
and the complexity associated with task migration. If we keep
a per-container list of pages, during task migration, you'll have
to migrate pages (of the task) from the list to the new container.
>> containers (by passing SC_OVERLIMIT_ALL). The idea behind using such a scheme
>> is to ensure that the global LRU list is not broken.
>
> isolate_lru_pages() helps in this. As far as I remember this
> was introduced to reduce lru lock contention and keep lru
> lists integrity.
>
> In beancounters patches this is used to shrink BC's pages.
I'll look at isolate_lru_pages() to see if the reclaim can be optimized.
Thanks for your feedback,
--
Balbir Singh,
Linux Technology Center,
IBM Software Labs
WARNING: multiple messages have this Message-ID (diff)
From: Balbir Singh <balbir@in.ibm.com>
To: Pavel Emelianov <xemul@openvz.org>
Cc: Linux MM <linux-mm@kvack.org>,
dev@openvz.org, ckrm-tech@lists.sourceforge.net,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
haveblue@us.ibm.com, rohitseth@google.com
Subject: Re: [RFC][PATCH 8/8] RSS controller support reclamation
Date: Fri, 10 Nov 2006 18:12:53 +0530 [thread overview]
Message-ID: <455473CD.10609@in.ibm.com> (raw)
In-Reply-To: <4554466F.8010602@openvz.org>
Pavel Emelianov wrote:
> Balbir Singh wrote:
>
> [snip]
>
>>> And what about a hard limit - how would you fail in page fault in
>>> case of limit hit? SIGKILL/SEGV is not an option - in this case we
>>> should run synchronous reclamation. This is done in beancounter
>>> patches v6 we've sent recently.
>>>
>> I thought about running synchronous reclamation, but then did not follow
>> that approach, I was not sure if calling the reclaim routines from the
>> page fault context is a good thing to do. It's worth trying out, since
>
> Each page fault potentially calls reclamation by allocating
> required page with __GFP_IO | __GFP_FS bits set. Synchronous
> reclamation in page fault is really normal.
True. I don't know what I was thinking, thanks for making me think
straight.
>
> [snip]
>
>>> Please correct me if I'm wrong, but does this reclamation work like
>>> "run over all the zones' lists searching for page whose controller
>>> is sc->container" ?
>>>
>> Yeah, that's correct. The code can also reclaim memory from all over-the-limit
>
> OK. What if I have a container with 100 pages limit in a 4Gb
> (~ million of pages) machine and this group starts reclaiming
> its pages. In case this group uses its pages heavily they will
> be at the beginning of an LRU list and reclamation code would
> have to scan through all (million) pages before it finds proper
> ones. This is not optimal!
>
Yes, thats possible. The trade off is between
The cost associated with traversing that list while reclaiming
and the complexity associated with task migration. If we keep
a per-container list of pages, during task migration, you'll have
to migrate pages (of the task) from the list to the new container.
>> containers (by passing SC_OVERLIMIT_ALL). The idea behind using such a scheme
>> is to ensure that the global LRU list is not broken.
>
> isolate_lru_pages() helps in this. As far as I remember this
> was introduced to reduce lru lock contention and keep lru
> lists integrity.
>
> In beancounters patches this is used to shrink BC's pages.
I'll look at isolate_lru_pages() to see if the reclaim can be optimized.
Thanks for your feedback,
--
Balbir Singh,
Linux Technology Center,
IBM Software Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2006-11-10 12:43 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-09 19:35 [RFC][PATCH 0/8] RSS controller for containers Balbir Singh
2006-11-09 19:35 ` Balbir Singh
2006-11-09 19:35 ` [RFC][PATCH 1/8] Fix resource groups parsing, while assigning shares Balbir Singh
2006-11-09 19:35 ` Balbir Singh
2006-11-09 19:35 ` [RFC][PATCH 2/8] RSS controller setup Balbir Singh
2006-11-09 19:35 ` Balbir Singh
2006-11-09 19:35 ` [RFC][PATCH 3/8] RSS controller add callbacks Balbir Singh
2006-11-09 19:35 ` Balbir Singh
2006-11-09 19:36 ` [RFC][PATCH 4/8] RSS controller accounting Balbir Singh
2006-11-09 19:36 ` Balbir Singh
2006-11-10 9:06 ` Pavel Emelianov
2006-11-10 9:06 ` Pavel Emelianov
2006-11-10 9:29 ` Balbir Singh
2006-11-10 9:29 ` Balbir Singh
2006-11-09 19:36 ` [RFC][PATCH 5/8] RSS controller task migration support Balbir Singh
2006-11-09 19:36 ` Balbir Singh
2006-11-09 19:36 ` [RFC][PATCH 6/8] RSS controller shares allocation Balbir Singh
2006-11-09 19:36 ` Balbir Singh
2006-11-10 9:11 ` Pavel Emelianov
2006-11-10 9:11 ` Pavel Emelianov
2006-11-10 10:27 ` [ckrm-tech] " Balbir Singh
2006-11-10 10:27 ` Balbir Singh
2006-11-10 10:32 ` Pavel Emelianov
2006-11-10 10:32 ` Pavel Emelianov
2006-11-10 12:55 ` Balbir Singh
2006-11-10 12:55 ` Balbir Singh
2006-11-09 19:36 ` [RFC][PATCH 7/8] RSS controller fix resource groups parsing Balbir Singh
2006-11-09 19:36 ` Balbir Singh
2006-11-10 9:13 ` Pavel Emelianov
2006-11-10 9:13 ` Pavel Emelianov
2006-11-10 9:32 ` Balbir Singh
2006-11-10 9:32 ` Balbir Singh
2006-11-09 19:36 ` [RFC][PATCH 8/8] RSS controller support reclamation Balbir Singh
2006-11-09 19:36 ` Balbir Singh
2006-11-09 19:45 ` Arjan van de Ven
2006-11-09 19:45 ` Arjan van de Ven
2006-11-10 1:56 ` [ckrm-tech] " Balbir Singh
2006-11-10 1:56 ` Balbir Singh
2006-11-10 8:54 ` Pavel Emelianov
2006-11-10 8:54 ` Pavel Emelianov
2006-11-10 9:16 ` Balbir Singh
2006-11-10 9:16 ` Balbir Singh
2006-11-10 9:29 ` Pavel Emelianov
2006-11-10 9:29 ` Pavel Emelianov
2006-11-10 12:42 ` Balbir Singh [this message]
2006-11-10 12:42 ` Balbir Singh
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=455473CD.10609@in.ibm.com \
--to=balbir@in.ibm.com \
--cc=ckrm-tech@lists.sourceforge.net \
--cc=dev@openvz.org \
--cc=haveblue@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rohitseth@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.