On Fri, Oct 26, 2001 at 06:54:00PM +0100, Alan Cox wrote:
> > simply because the <2.4.10 buffer cache layer wasn't able to do proper
> > readahead on the blkdev. Now we do readahead properly and so in turn
> > the the lack of media-change trust of the vfs shows up. So as far I can
> > tell the right fix have no influence on the blkdev in pagecache, but it
> > only consists in resurrecting the media-change detection with a
> > per-device bitflag whitelist. I cannot see other source of stalls across
> > a close/open cycle.
>
> I'm not currently sure if the impact is from the cost of the page cache
> flushing or the invalidate/re-read it triggers. There probably are two or
> three seeks on the DVD if the data is invalidated so that would make sense.
plus we also need to wait completion of the readahead synchronously in
the cache flushing at close, the larger the readahead, the larger the
stall.
I doubt the cpu cost of truncate_inode_pages as originally suspected
is the culprit, more likely the fact we have to wait for a larger I/O to
complete plus the disk seek due the fact we throw away the readahead,
infact invalidate_buffers in-cpu-core cost in -ac could be lot worse
considering it has to walk a list that contains all kind of buffers not
only belonging to the interesting device to flush.
But anyways the media change detection will avoid to throw away the
readahead and in turn it will avoid the seek, it will avoid the
synchronous I/O completion wait in truncate_inode_pages, and it will
avoid the truncate_inode_pages in-cpu-core cost cost as well, so it
should most certainly fix the problem.
Andrea
-
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/
This archive was generated by hypermail 2b29 : Wed Oct 31 2001 - 21:00:31 EST