[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <45470FEE.6040605@openvz.org>
Date: Tue, 31 Oct 2006 11:57:18 +0300
From: Pavel Emelianov <xemul@...nvz.org>
To: balbir@...ibm.com
CC: vatsa@...ibm.com, dev@...nvz.org, sekharan@...ibm.com,
ckrm-tech@...ts.sourceforge.net, haveblue@...ibm.com,
linux-kernel@...r.kernel.org, pj@....com, matthltc@...ibm.com,
dipankar@...ibm.com, rohitseth@...gle.com, menage@...gle.com,
linux-mm@...ck.org
Subject: Re: [ckrm-tech] RFC: Memory Controller
[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.
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists