Messages in this thread | | | Date | Fri, 16 Feb 2001 10:53:51 -0500 | From | David Mansfield <> |
| |
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/
| |