linux-kernel - Re: [RFC] Using "page credits" as a solution for common thrashing scenarios

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: <4B0310CD.6050303@redhat.com>
Date:	Tue, 17 Nov 2009 16:08:29 -0500
From:	Rik van Riel <riel@...hat.com>
To:	Eyal Lotem <eyal.lotem@...il.com>
CC:	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] Using "page credits" as a solution for common thrashing
 	scenarios

On 11/17/2009 03:52 PM, Eyal Lotem wrote:
> Highly simplified example of suggested solution (numbers are made up):
>
> NOTE: The example does not include shared library memory use and various
> other details (I do believe this solution handles those elegantly), to
> avoid clutter.
>
>    
The real problematic details are in the data structures.

How to organize the pages in-kernel?

How does the kernel find the pages with the lowest
score?  In the memory zone where memory needs
to be freed...

How can the kernel efficiently change the score of
tens of thousands (or even millions) of pages at once,
moving them to the right LRU list cheaply?

Making page replacement scale to systems with
hundreds of gigabytes of memory is a necessity, as
is evicting the right kind of page (filesystem cache
vs process page, etc).

Within those constraints, it becomes very hard to
implement a solution along your ideas.
--
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/