> Please have a look at the following patch and feel free to be scared
> by the fact how UTTERLY BROKEN and ARBITRARY the current usage of the
> read_ahead[] array and during the whole past decade was!
> If you really care about clean internal interfaces this should be
> one of those prio number ONE targets to shoot at...
>
> The most amanzing thing is that the whole test10-pre5 kernel with this
> patch applied doesn't show any performance penalties for me at all!
> And of corse it's about 10k smaller...
I agree with you and Rik that this array needs to go away... but
ripping out the feature is not the answer, IMHO.
Can you work up a patch that instead changes the readahead to be a hash
table? The key could be a hash of the blkdev/chrdev pointer value (or
kdev_t for now). Considering the number of users, the hash table can be
pretty darn small for most machines, but we can easily scale its size
dynamically at boot if need be.
That would give us the per-device granularity we need to actually make
the feature useful, and allow us to kill the hacks you mention in
existing drivers (like the MD and SCSI examples you cited).
Jeff
-- Jeff Garzik | The difference between laziness and Building 1024 | prioritization is the end result. MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Oct 31 2000 - 21:00:14 EST