linux-kernel - Re: [PATCH 0/3] readahead drop behind and size adjustment

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: <46A76D58.40604@redhat.com>
Date:	Wed, 25 Jul 2007 11:33:44 -0400
From:	Rik van Riel <riel@...hat.com>
To:	Nick Piggin <nickpiggin@...oo.com.au>
CC:	Eric St-Laurent <ericstl34@...patico.ca>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Fengguang Wu <fengguang.wu@...il.com>,
	Dave Jones <davej@...hat.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Tim Pepper <lnxninja@...ibm.com>,
	Chris Snook <csnook@...hat.com>
Subject: Re: [PATCH 0/3] readahead drop behind and size adjustment

Nick Piggin wrote:
> Eric St-Laurent wrote:
>> On Wed, 2007-25-07 at 15:19 +1000, Nick Piggin wrote:
>>
>>
>>> What *I* think is supposed to happen is that newly read in pages get
>>> put on the inactive list, and unless they get accessed againbefore
>>> being reclaimed, they are allowed to fall off the end of the list
>>> without disturbing active data too much.
>>>
>>> I think there is a missing piece here, that we used to ease the reclaim
>>> pressure off the active list when the inactive list grows relatively
>>> much larger than it (which could indicate a lot of use-once pages in
>>> the system).
>>
>>
>> Maybe a new list should be added to put newly read pages in it. If they
>> are not used or used once after a certain period, they can be moved to
>> the inactive list (or whatever).
>>
>> Newly read pages...
>>
>> - ... not used after this period are excessive readahead, we discard
>> immediately.
>> - ... used only once after this period, we discard soon.
>> - ... used many/frequently are moved to active list.
>>
>> Surely the scan rate (do I make sense?) should be different for this
>> newly-read list and the inactive list. 
> 
> A new list could be a possibility. One problem with adding lists is just
> trying to work out how to balance scanning rates between them, another
> problem is CPU overhead of moving pages from one to another... but don't
> let me stop you if you want to jump in and try something :)
> 
> 
>> I also remember your split mapped/unmapped active list patches from a
>> while ago.
>>
>> Can someone point me to a up-to-date documentation about the Linux VM?
>> The books and documents I've seen are outdated.
> 
> If you just want to play with page reclaim algorithms, try reading over
> mm/vmscan.c. If you don't know much about the Linux VM internals before,
> don't worry too much about the fine details and start by getting an idea
> of how pages move between the active and inactive lists.

I've got a nice list of problems with the VM at
http://linux-mm.org/PageoutFailureModes :)

I should post my latest version of the split LRU
lists code.  I'm still working on SEQ replacement
for the anonymous pages...

> OK here is one which just changes the rate that the active and inactive
> lists get scanned. Data corruption bugs should be minimal ;)

I had something like that in mind for the file
pages.  I am a bit nervous about introducing
such a change while file and anonymous pages
share the same LRU, though...

-- 
Politics is the struggle between those who want to make their country
the best in the world, and those who believe it already is.  Each group
calls the other unpatriotic.
-
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/