linux-kernel - Re: Why active list and inactive list?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <45B59322.1070603@in.ibm.com>
Date:	Tue, 23 Jan 2007 10:16:26 +0530
From:	Balbir Singh <balbir@...ibm.com>
To:	Nick Piggin <nickpiggin@...oo.com.au>
CC:	Andrea Arcangeli <andrea@...e.de>,
	Niki Hammler <mailinglists@...aq.net>,
	linux-kernel@...r.kernel.org,
	Vaidyanathan Srinivasan <svaidy@...ux.vnet.ibm.com>
Subject: Re: Why active list and inactive list?

Nick Piggin wrote:
> 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)
> 
> I actually had patches to do "split active lists" a while back.
> 
> They worked by lazily moving the page at reclaim-time, based on
> whether or not it is mapped. This isn't too much worse than the
> kernel's current idea of what a mapped page is.
> 
> They actually got a noticable speedup of the swapping kbuild
> workload, but at this stage there were some more basic
> improvements needed, so the difference could be smaller today.
> 
> The other nice thing about it was that it didn't have a hard
> cutoff that the current reclaim_mapped toggle does -- you could
> opt to scan the mapped list at a lower ratio than the unmapped
> one. Of course, it also has some downsides too, and would
> require retuning...
> 

Thanks, I am motivated to experiment with the idea. I guess I need
to (re)discover the downsides for myself :-)

-- 
	Balbir Singh
	Linux Technology Center
	IBM, ISTL
-
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/