linux-kernel - Re: [RFC PATCH 0/10] split anon and file LRUs

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20071107131627.57e8f666@bree.surriel.com>
Date:	Wed, 7 Nov 2007 13:16:27 -0500
From:	Rik van Riel <riel@...hat.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	clameter@....com, linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/10] split anon and file LRUs

On Wed, 7 Nov 2007 09:59:45 -0800
Andrew Morton <akpm@...ux-foundation.org> wrote:

> > On Tue, 6 Nov 2007 21:51:27 -0500 Rik van Riel <riel@...hat.com> wrote:

> > Which is why we need to greatly reduce the number of pages
> > scanned to free a page.  In all workloads.
> 
> It strikes me that splitting one list into two lists will not provide
> sufficient improvement in search efficiency to do that. 

Well, if you look at the typical problem systems today, you
will see that most of the pages being allocated and evicted
are in the page cache, while most of the pages in memory are
actually anonymous pages.

Not having to scan over that 80% of memory that contains
anonymous pages and shared memory segments to get at the
20% page cache pages is much more than a factor two
improvement.

> I mean, a naive guess would be that it will, on average, halve the amount
> of work which needs to be done.
> 
> But we need multiple-orders-of-magnitude improvements to address the
> pathological worst-cases which you're looking at there.  Where is this
> coming from?

Replacing page cache pages is easy.  If they were referenced
once (typical), we can just evict the page the first time we
scan it.

Anonymous pages have a similar optimization: every anonymous
page starts out referenced, so moving referenced pages back
to the front of the active list is unneeded work.

However, we cannot just place referenced anonymous pages onto
an inactive list that is shared with page cache pages, because
of the difference in replacement cost and relative importance
of both types of pages!

> Or is the problem which you're seeing due to scanning of mapped pages
> at low "distress" levels?
> 
> Would be interested in seeing more details on all of this, please.

http://linux-mm.org/PageReplacementDesign

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
-
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/