lkml.org 
[lkml]   [2001]   [Feb]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Andrea Arcangeli wrote:
>
> On Wed, Jan 24, 2001 at 04:05:12PM +0100, Sasi Peter wrote:
> > > This isn't obvious. Your working may not fit in cache and so the kernel
> > > understand it's worthless to swapout stuff to make space to a polluted
> > > cache.
> >
> > But your understanding agrees on that the larger chunks for each stream
> > we read into cache, the more efficient for this kind of RAID disk
> > structure the read is, thus basically the more cache we have, the more
> > bandwidth we can serve. (disks give more data in the same time with
> > fewer long reads than with several shorter ones)
>
> The size of the I/O requests doesn't grow linearly with with the size of the
> cache, as far as you have some mbyte of cache you will also be able to sumbit
> full sized requests to disk (512K per req on 2.4). In your workload you just
> had enough memory for the readahead.
>
> In general if your working set doesn't fit in cache, the size of the cache is
> unrelated to the bandwith you get out of your RAID, infact if your working set
> doesn't fit in cache you should not pass through the cache at all to get the
> best performance and to save CPU cycles and L1 dcache and L2 cache (O_DIRECT).
>

This may be a bit OT, but when you say O_DIRECT, that implies that you
can pass that flag to open(2) and it will bypass the page cache, and
read directly into user-space buffers (zero-copy IO)? Does this also
bypass the read-ahead mechanisms in the kernel? Does it imply O_SYNC?

Lots of questions... no answers. Sigh.

David

--
David Mansfield (718) 963-2020
david@ultramaster.com
Ultramaster Group, LLC www.ultramaster.com
-
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 13:15    [W:0.111 / U:0.448 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site