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/