Messages in this thread | | | Date | Sat, 19 May 2007 21:02:02 +0800 | From | Fengguang Wu <> | Subject | Re: [PATCH 5/9] readahead: on-demand readahead logic |
| |
On Fri, May 18, 2007 at 11:23:35PM -0700, Andrew Morton wrote: > > That would have to be the best changelog I've ever seen ;) Thanks for > persisting with this.
Thank you :)
> > sysbench oltp (trans/sec): up to 8% gain > > Have you given any thought to identifying workloads which may be worsened > by your changes? Attempt to deliberately expose any weak spots?
Yeah. All possible downsides I can imagine are:
- CPU overheads Only random reads will be hurt. That's 1% slow down for _sparse files_, and should be much smaller when real I/O is involved.
- Behavior changes It do not enforce strict check sequentialness. - it is in general a good behavior for interleaved reads and clustered-and-intermixed-random/sequential workloads. - it might lead to more readahead misses E.g. a random read sequence of 0,1,4,12,28,60,92,124,156,188,220 that is weird enough to start the readahead and hit all the lookahead pages. I highly doubt the possibility of such patterns happen in real world. But if ever it happens repeatedly for some user, he can work it around easily by tuning readahead_kb to some other value.
So, it is only a possibility that some random workload may be worsened. But it's really hard to find one real world example.
- 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/
| |