linux-kernel - Re: Improvement on memory subsystem

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: <200607181218.k6ICIgeS027067@turing-police.cc.vt.edu>
Date:	Tue, 18 Jul 2006 08:18:42 -0400
From:	Valdis.Kletnieks@...edu
To:	yunfeng zhang <zyf.zeroos@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Improvement on memory subsystem

On Tue, 18 Jul 2006 18:03:54 +0800, yunfeng zhang said:

> 2. Read-ahead process during page-in/out (page fault or swap out) should be
> based on its VMA to enhance IO efficiency instead of the relative physical pages
> in swap space.

But wouldn't that end up causing a seek storm, rather than handling the pages
in the order that minimizes the total seek distance, no matter where they are
in memory? Remember - if you have a 2Ghz processor, and a disk that seeks in 1
millisecond, every seek is (*very* roughly) about 2 million instructions.  So
if we can burn 20 thousand instructions finding a read order that eliminates
*one* seek, we're 1.98M instructions ahead.

Now, if you have an improved read-ahead that spews out page requests that
are both elevator-friendly and temporal-friendly, *then* you might be onto
something.  For instance, if you can identify 80 pages that will likely be
needed in the next 50 milliseconds, of which 50 pages will be likely needed
in the next 30ms, you want to issue those 50 first, in an elevator-friendly
manner (uncaffienated handwave here) - and then issue the other 30 page
requests in a second burst the next time the elevator goes by.  Note this
requires the read-ahead to get a *lot* more chummy with the elevator than
it seems to currently.  In particular, readahead would need to need to be
able to hold off submitting the "later" 30 pages until it could be sure
that the elevator wouldn't merge them into the queue in a way that would
slow down the first 50 requests.

If it does that already, somebody just smack me.  And if there's a good
reason not to do that, hand me some caffeine and a clue. :)

Content of type "application/pgp-signature" skipped