From: Balbir Singh <balbir@in.ibm.com>
To: Pavel Emelianov <xemul@openvz.org>
Cc: vatsa@in.ibm.com, dev@openvz.org, sekharan@us.ibm.com,
ckrm-tech@lists.sourceforge.net, haveblue@us.ibm.com,
linux-kernel@vger.kernel.org, pj@sgi.com, matthltc@us.ibm.com,
dipankar@in.ibm.com, rohitseth@google.com, menage@google.com,
linux-mm@kvack.org, Vaidyanathan S <svaidy@in.ibm.com>
Subject: Re: [ckrm-tech] RFC: Memory Controller
Date: Tue, 31 Oct 2006 15:40:59 +0530 [thread overview]
Message-ID: <45472133.9090109@in.ibm.com> (raw)
In-Reply-To: <45471679.90103@openvz.org>
Pavel Emelianov wrote:
> Balbir Singh wrote:
>> Pavel Emelianov wrote:
>>> [snip]
>>>
>>>>> But in general I agree, these are the three important resources for
>>>>> accounting and control
>>>> I missed out to mention, I hope you were including the page cache in
>>>> your definition of reclaimable memory.
>>> As far as page cache is concerned my opinion is the following.
>>> (If I misunderstood you, please correct me.)
>>>
>>> Page cache is designed to keep in memory as much pages as
>>> possible to optimize performance. If we start limiting the page
>>> cache usage we cut the performance. What is to be controlled is
>>> _used_ resources (touched pages, opened file descriptors, mapped
>>> areas, etc), but not the cached ones. I see nothing bad if the
>>> page that belongs to a file, but is not used by ANY task in BC,
>>> stays in memory. I think this is normal. If kernel wants it may
>>> push this page out easily it won't event need to try_to_unmap()
>>> it. So cached pages must not be accounted.
>>>
>> The idea behind limiting the page cache is this
>>
>> 1. Lets say one container fills up the page cache.
>> 2. The other containers will not be able to allocate memory (even
>> though they are within their limits) without the overhead of having
>> to flush the page cache and freeing up occupied cache. The kernel
>> will have to pageout() the dirty pages in the page cache.
>>
>> Since it is easy to push the page out (as you said), it should be
>> easy to impose a limit on the page cache usage of a container.
>
> If a group is limited with memory _consumption_ it won't fill
> the page cache...
>
So you mean the memory _consumption_ limit is already controlling
the page cache? That's what we need the ability for a container
not to fill up the page cache :)
I don't remember correctly, but do you account for dirty page cache usage in
the latest patches of BC?
>>> I've also noticed that you've [snip]-ed on one of my questions.
>>>
>>> > How would you allocate memory on NUMA in advance?
>>>
>>> Please, clarify this.
>> I am not quite sure I understand the question. Could you please rephrase
>> it and highlight some of the difficulty?
>
> I'd like to provide a guarantee for a newly created group. According
> to your idea I have to preallocate some pages in advance. OK. How to
> select a NUMA node to allocate them from?
The idea of pre-allocation was discussed as a possibility in the case
that somebody needed hard guarantees, but most of us don't need it.
I was in the RFC for the sake of completeness.
Coming back to your question
Why do you need to select a NUMA node? For performance?
--
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: vatsa@in.ibm.com, dev@openvz.org, sekharan@us.ibm.com,
ckrm-tech@lists.sourceforge.net, haveblue@us.ibm.com,
linux-kernel@vger.kernel.org, pj@sgi.com, matthltc@us.ibm.com,
dipankar@in.ibm.com, rohitseth@google.com, menage@google.com,
linux-mm@kvack.org, Vaidyanathan S <svaidy@in.ibm.com>
Subject: Re: [ckrm-tech] RFC: Memory Controller
Date: Tue, 31 Oct 2006 15:40:59 +0530 [thread overview]
Message-ID: <45472133.9090109@in.ibm.com> (raw)
In-Reply-To: <45471679.90103@openvz.org>
Pavel Emelianov wrote:
> Balbir Singh wrote:
>> Pavel Emelianov wrote:
>>> [snip]
>>>
>>>>> But in general I agree, these are the three important resources for
>>>>> accounting and control
>>>> I missed out to mention, I hope you were including the page cache in
>>>> your definition of reclaimable memory.
>>> As far as page cache is concerned my opinion is the following.
>>> (If I misunderstood you, please correct me.)
>>>
>>> Page cache is designed to keep in memory as much pages as
>>> possible to optimize performance. If we start limiting the page
>>> cache usage we cut the performance. What is to be controlled is
>>> _used_ resources (touched pages, opened file descriptors, mapped
>>> areas, etc), but not the cached ones. I see nothing bad if the
>>> page that belongs to a file, but is not used by ANY task in BC,
>>> stays in memory. I think this is normal. If kernel wants it may
>>> push this page out easily it won't event need to try_to_unmap()
>>> it. So cached pages must not be accounted.
>>>
>> The idea behind limiting the page cache is this
>>
>> 1. Lets say one container fills up the page cache.
>> 2. The other containers will not be able to allocate memory (even
>> though they are within their limits) without the overhead of having
>> to flush the page cache and freeing up occupied cache. The kernel
>> will have to pageout() the dirty pages in the page cache.
>>
>> Since it is easy to push the page out (as you said), it should be
>> easy to impose a limit on the page cache usage of a container.
>
> If a group is limited with memory _consumption_ it won't fill
> the page cache...
>
So you mean the memory _consumption_ limit is already controlling
the page cache? That's what we need the ability for a container
not to fill up the page cache :)
I don't remember correctly, but do you account for dirty page cache usage in
the latest patches of BC?
>>> I've also noticed that you've [snip]-ed on one of my questions.
>>>
>>> > How would you allocate memory on NUMA in advance?
>>>
>>> Please, clarify this.
>> I am not quite sure I understand the question. Could you please rephrase
>> it and highlight some of the difficulty?
>
> I'd like to provide a guarantee for a newly created group. According
> to your idea I have to preallocate some pages in advance. OK. How to
> select a NUMA node to allocate them from?
The idea of pre-allocation was discussed as a possibility in the case
that somebody needed hard guarantees, but most of us don't need it.
I was in the RFC for the sake of completeness.
Coming back to your question
Why do you need to select a NUMA node? For performance?
--
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-10-31 10:12 UTC|newest]
Thread overview: 151+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-30 10:33 [RFC] Resource Management - Infrastructure choices Srivatsa Vaddagiri
2006-10-30 10:34 ` RFC: Memory Controller Balbir Singh
2006-10-30 11:04 ` Paul Menage
2006-10-30 13:27 ` [ckrm-tech] " Balbir Singh
2006-10-30 18:14 ` Paul Menage
2006-10-31 17:07 ` Balbir Singh
2006-10-31 17:22 ` Paul Menage
2006-10-31 18:16 ` Badari Pulavarty
2006-11-01 7:05 ` Balbir Singh
2006-11-01 7:07 ` Paul Menage
2006-11-01 7:44 ` Balbir Singh
2006-11-01 12:23 ` Paul Jackson
2006-11-02 0:09 ` Paul Menage
2006-11-02 0:39 ` Paul Jackson
2006-10-30 15:58 ` Pavel Emelianov
2006-10-30 17:39 ` Balbir Singh
2006-10-30 18:07 ` Balbir Singh
2006-10-30 18:07 ` Balbir Singh
2006-10-31 8:57 ` Pavel Emelianov
2006-10-31 8:57 ` Pavel Emelianov
2006-10-31 9:19 ` Balbir Singh
2006-10-31 9:19 ` Balbir Singh
2006-10-31 9:25 ` Pavel Emelianov
2006-10-31 9:25 ` Pavel Emelianov
2006-10-31 10:10 ` Balbir Singh [this message]
2006-10-31 10:10 ` Balbir Singh
2006-10-31 10:19 ` Pavel Emelianov
2006-10-31 10:19 ` Pavel Emelianov
2006-10-31 9:42 ` Andrew Morton
2006-10-31 9:42 ` Andrew Morton
2006-10-31 10:36 ` Balbir Singh
2006-10-31 10:36 ` Balbir Singh
2006-10-31 8:48 ` Pavel Emelianov
2006-10-31 10:54 ` Balbir Singh
2006-10-31 10:54 ` Balbir Singh
2006-10-31 11:15 ` Pavel Emelianov
2006-10-31 11:15 ` Pavel Emelianov
2006-10-31 12:39 ` Balbir Singh
2006-10-31 12:39 ` Balbir Singh
2006-10-31 14:19 ` Pavel Emelianov
2006-10-31 14:19 ` Pavel Emelianov
2006-10-31 16:54 ` Paul Menage
2006-10-31 16:54 ` Paul Menage
2006-11-01 6:00 ` David Rientjes
2006-11-01 6:00 ` David Rientjes
2006-11-01 8:05 ` Pavel Emelianov
2006-11-01 8:05 ` Pavel Emelianov
2006-11-01 8:35 ` David Rientjes
2006-11-01 8:35 ` David Rientjes
2006-10-31 17:04 ` Dave Hansen
2006-11-01 7:57 ` Pavel Emelianov
2006-10-30 18:20 ` Paul Menage
2006-10-30 21:38 ` Paul Jackson
2006-10-30 10:43 ` [RFC] Resource Management - Infrastructure choices Paul Jackson
2006-10-30 14:19 ` [ckrm-tech] " Pavel Emelianov
2006-10-30 14:29 ` Paul Jackson
2006-10-30 17:09 ` Srivatsa Vaddagiri
2006-10-30 17:16 ` Dave McCracken
2006-10-30 18:07 ` Paul Menage
2006-10-30 20:41 ` Paul Jackson
2006-10-30 10:51 ` Paul Menage
2006-10-30 11:06 ` [ckrm-tech] " Paul Jackson
2006-10-30 12:07 ` Paul Menage
2006-10-30 12:28 ` Paul Jackson
2006-10-30 11:15 ` Paul Jackson
2006-10-30 12:04 ` Paul Menage
2006-10-30 12:27 ` Paul Jackson
2006-10-30 17:53 ` Paul Menage
2006-10-30 20:36 ` Paul Jackson
2006-10-30 20:47 ` Paul Menage
2006-10-30 20:56 ` Paul Jackson
2006-10-30 21:03 ` Paul Menage
2006-10-31 11:53 ` Srivatsa Vaddagiri
2006-10-31 13:31 ` Srivatsa Vaddagiri
2006-10-31 16:46 ` Paul Menage
2006-11-01 17:25 ` Srivatsa Vaddagiri
2006-11-01 23:37 ` Paul Menage
2006-11-06 12:49 ` Srivatsa Vaddagiri
2006-11-06 20:23 ` Paul Menage
2006-11-07 13:20 ` Srivatsa Vaddagiri
2006-11-07 18:41 ` Paul Jackson
2006-11-07 19:07 ` Paul Menage
2006-11-07 19:11 ` Paul Jackson
2006-11-07 19:24 ` Paul Menage
2006-11-07 19:58 ` Paul Jackson
2006-11-07 20:00 ` Paul Menage
2006-11-07 20:02 ` Paul Jackson
2006-11-08 2:47 ` Matt Helsley
2006-11-07 20:34 ` Paul Jackson
2006-11-07 20:41 ` Paul Menage
2006-11-07 21:50 ` Paul Jackson
2006-11-07 22:21 ` Paul Menage
2006-11-08 3:15 ` Paul Jackson
2006-11-08 4:15 ` Paul Menage
2006-11-08 4:16 ` Paul Jackson
2006-11-08 11:22 ` Paul Jackson
2006-11-08 5:12 ` Srivatsa Vaddagiri
2006-11-08 5:36 ` Paul Jackson
2006-11-09 5:39 ` Balbir Singh
2006-11-08 19:25 ` Chris Friesen
2006-11-09 3:54 ` Srivatsa Vaddagiri
2006-11-10 14:57 ` Srivatsa Vaddagiri
2006-11-01 4:39 ` David Rientjes
2006-11-01 9:50 ` Paul Jackson
2006-11-01 9:58 ` David Rientjes
2006-11-01 15:59 ` Srivatsa Vaddagiri
2006-11-01 16:31 ` Srivatsa Vaddagiri
2006-11-01 21:05 ` David Rientjes
2006-11-01 23:43 ` Paul Menage
2006-11-01 18:19 ` Srivatsa Vaddagiri
2006-11-01 17:33 ` Srivatsa Vaddagiri
2006-11-01 21:18 ` Chris Friesen
2006-11-01 23:01 ` [Devel] " Kir Kolyshkin
2006-11-02 0:31 ` Matt Helsley
2006-11-02 8:34 ` Kir Kolyshkin
2006-11-01 23:48 ` Paul Menage
2006-11-02 3:28 ` Chris Friesen
2006-11-02 7:40 ` Paul Menage
2006-10-30 14:08 ` Pavel Emelianov
2006-10-30 14:23 ` Paul Jackson
2006-10-30 14:38 ` Pavel Emelianov
2006-10-30 15:18 ` Paul Jackson
2006-10-30 15:26 ` Pavel Emelianov
2006-10-31 0:26 ` Matt Helsley
2006-10-31 8:34 ` Pavel Emelianov
2006-10-31 16:33 ` Chris Friesen
2006-10-30 18:01 ` Paul Menage
2006-10-31 8:31 ` Pavel Emelianov
2006-10-31 16:34 ` Paul Menage
2006-10-31 16:57 ` Srivatsa Vaddagiri
2006-11-01 7:58 ` Pavel Emelianov
2006-10-31 16:34 ` Srivatsa Vaddagiri
2006-11-01 8:01 ` Pavel Emelianov
2006-11-01 16:04 ` Matt Helsley
2006-11-01 17:51 ` Srivatsa Vaddagiri
2006-11-01 17:50 ` Srivatsa Vaddagiri
2006-11-02 8:42 ` Pavel Emelianov
2006-11-03 1:29 ` David Rientjes
2006-11-01 9:30 ` Pavel Emelianov
2006-11-01 9:53 ` David Rientjes
2006-11-01 22:23 ` Matt Helsley
2006-11-01 18:12 ` Srivatsa Vaddagiri
2006-11-01 22:19 ` Matt Helsley
2006-11-01 23:50 ` Paul Menage
2006-11-02 0:30 ` Matt Helsley
2006-11-02 5:33 ` Balbir Singh
2006-11-02 9:08 ` Pavel Emelianov
2006-11-02 11:26 ` Matt Helsley
2006-11-02 13:04 ` Pavel Emelianov
2006-11-03 1:29 ` David Rientjes
2006-11-02 8:52 ` Pavel Emelianov
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=45472133.9090109@in.ibm.com \
--to=balbir@in.ibm.com \
--cc=ckrm-tech@lists.sourceforge.net \
--cc=dev@openvz.org \
--cc=dipankar@in.ibm.com \
--cc=haveblue@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=matthltc@us.ibm.com \
--cc=menage@google.com \
--cc=pj@sgi.com \
--cc=rohitseth@google.com \
--cc=sekharan@us.ibm.com \
--cc=svaidy@in.ibm.com \
--cc=vatsa@in.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 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.