From: Pavel Emelianov <xemul@openvz.org>
To: balbir@in.ibm.com
Cc: Pavel Emelianov <xemul@openvz.org>,
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 12:25:13 +0300 [thread overview]
Message-ID: <45471679.90103@openvz.org> (raw)
In-Reply-To: <45471510.4070407@in.ibm.com>
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...
>> 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?
--
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 9:25 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20061030103356.GA16833@in.ibm.com>
[not found] ` <4545D51A.1060808@in.ibm.com>
[not found] ` <4546212B.4010603@openvz.org>
[not found] ` <454638D2.7050306@in.ibm.com>
2006-10-30 18:07 ` Balbir Singh
2006-10-31 8:57 ` Pavel Emelianov
2006-10-31 9:19 ` Balbir Singh
2006-10-31 9:25 ` Pavel Emelianov [this message]
2006-10-31 10:10 ` Balbir Singh
2006-10-31 10:19 ` Pavel Emelianov
2006-10-31 9:42 ` Andrew Morton
2006-10-31 10:36 ` Balbir Singh
[not found] ` <45470DF4.70405@openvz.org>
2006-10-31 10:54 ` Balbir Singh
2006-10-31 11:15 ` Pavel Emelianov
2006-10-31 12:39 ` Balbir Singh
2006-10-31 14:19 ` Pavel Emelianov
2006-10-31 16:54 ` Paul Menage
2006-11-01 6:00 ` David Rientjes
2006-11-01 8:05 ` Pavel Emelianov
2006-11-01 8:35 ` David Rientjes
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=45471679.90103@openvz.org \
--to=xemul@openvz.org \
--cc=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 \
/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