lkml.org 
[lkml]   [2001]   [Aug]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [resent PATCH] Re: very slow parallel read performance
--On Monday, 27 August, 2001 4:31 PM +0200 Daniel Phillips 
<phillips@bonn-fries.net> wrote:

> - Readahead cache is important enough to get its own lru list.
> We know it's a fifo so don't have to waste cycles scanning/aging.
> Having a distinct list makes the accounting trivial, vs keeping
> readahead on the active list for example.

A nit: I think it's a MRU list you want. If you are reading
ahead (let's have caps for a page that has been used for reading,
as well as read from the disk, and lowercase for read-ahead that
has not been used):
ABCDefghijklmnopq
| |
read disk
ptr head
and you want to reclaim memory, you want to drop (say) 'pq'
to get
ABCDefghijklmno
for two reasons: firstly because 'efg' etc. are most likely
to be used NEXT, and secondly because the diskhead is nearer
'pq' when you (inevitably) have to read it again.

This seems even more imporant when considering multiple streams,
as if you drop the least recently 'used' (i.e. read in from disk),
you will instantly create a thrashing storm.

And an idea: when dropping read-ahead pages, you might be better
dropping many readahed pages for a single stream, rather than
hitting them all equally, else they will tend to run out of
readahead in sync.

--
Alex Bligh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:58    [W:0.125 / U:0.176 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site