Messages in this thread | | | Date | Tue, 24 Oct 2000 14:54:45 -0400 | From | Jeff Garzik <> | Subject | Re: PATCH: killing read_ahead[] |
| |
> 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/
| |