From: Balbir Singh <balbir@in.ibm.com>
To: Christoph Lameter <clameter@sgi.com>
Cc: Andrea Arcangeli <andrea@suse.de>,
Niki Hammler <mailinglists@nobaq.net>,
linux-kernel@vger.kernel.org,
Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
Subject: Re: Why active list and inactive list?
Date: Tue, 23 Jan 2007 08:48:11 +0530 [thread overview]
Message-ID: <45B57E73.3000307@in.ibm.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0701221737510.30455@schroedinger.engr.sgi.com>
Christoph Lameter wrote:
> On Tue, 23 Jan 2007, Balbir Singh wrote:
>
>> This makes me wonder if it makes sense to split up the LRU into page
>> cache LRU and mapped pages LRU. I see two benefits
>>
>> 1. Currently based on swappiness, we might walk an entire list
>> searching for page cache pages or mapped pages. With these
>> lists separated, it should get easier and faster to implement
>> this scheme
>> 2. There is another parallel thread on implementing page cache
>> limits. If the lists split out, we need not scan the entire
>> list to find page cache pages to evict them.
>>
>> Of course I might be missing something (some piece of history)
>
> This means page cache = unmapped file backed page right? Otherwise this
> would not work. I always thought that the page cache were all file backed
> pages both mapped and unmapped.
>
Yes, unfortunately my terminology was not clear. I mean unmapped file
backed pages.
> With the proposed schemd you would have to move pages between lists if
> they are mapped and unmapped by a process. Terminating a process could
> lead to lots of pages moving to the unnmapped list.
>
When you unmap or map, you need to touch the pte entries and know the
pages involved, so shouldn't be equivalent to a list_del and list_add
for each page impacted by the map/unmap operation?
--
Balbir Singh
Linux Technology Center
IBM, ISTL
next prev parent reply other threads:[~2007-01-23 3:18 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-23 0:10 Why active list and inactive list? Niki Hammler
2007-01-23 0:39 ` Andrea Arcangeli
2007-01-23 1:31 ` Balbir Singh
2007-01-23 1:40 ` Christoph Lameter
2007-01-23 1:49 ` Rik van Riel
2007-01-23 2:03 ` Christoph Lameter
2007-01-23 2:17 ` Rik van Riel
2007-01-23 2:44 ` Christoph Lameter
2007-01-23 2:50 ` Rik van Riel
2007-01-23 8:29 ` Peter Zijlstra
2007-01-23 15:02 ` Rik van Riel
2007-01-30 11:01 ` Howard Chu
2007-01-23 3:36 ` Balbir Singh
2007-01-23 3:43 ` Christoph Lameter
2007-01-23 3:51 ` Balbir Singh
2007-01-23 3:18 ` Balbir Singh [this message]
2007-01-23 3:28 ` Christoph Lameter
2007-01-23 3:45 ` Balbir Singh
2007-01-23 3:51 ` Christoph Lameter
2007-01-23 1:42 ` Rik van Riel
2007-01-23 2:13 ` Andrea Arcangeli
2007-01-23 4:17 ` Nick Piggin
2007-01-23 4:34 ` Rik van Riel
2007-01-23 5:51 ` Balbir Singh
2007-01-23 4:46 ` Balbir Singh
[not found] <7Gpmk-5fN-21@gated-at.bofh.it>
2007-01-30 10:23 ` Howard Chu
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=45B57E73.3000307@in.ibm.com \
--to=balbir@in.ibm.com \
--cc=andrea@suse.de \
--cc=clameter@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mailinglists@nobaq.net \
--cc=svaidy@linux.vnet.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 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.