[lkml]   [2000]   [Oct]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: PATCH: killing read_ahead[]
Rik van Riel wrote:
> On Tue, 24 Oct 2000, Martin Dalecki wrote:
> > 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...
> Ideally we should (IMHO) get rid of all MAX_BLKDEV arrays.
> They take up too much memory on small systems and aren't
> big enough for big systems...

Yes sure. The whole patch was just showing how those arrays actually
HURT (the whole familiy of them)

1. Nobody really understands where which read_ahead does matter.

2. There is no discrimination between different device types on the same
major number....

3. MD and SCSI "work around" this by setting ridiculously high read
values... so you don't see the impact of this DAMN interface in

4. It's not just a problem of block devices it's a problem of char dev's
as well.

5. Removing them is a prerequisite for getting rid of the STIUPID
MAJOR(dev)/MINOR(dev) and famility of macros.... and of course wide
major infor number spaes as well...

6. It's showing that it was a BAD IDEA to intermix block/char majors.

7. It's really really confusing many many device driver developers.
Nobody seems to understand the intended semantics any longer.
In esp. in parts of the kernel which got introduced past the 2.0

and so on...

and of cores all the arrays involved in this game are:
Controller->GenericDiskInfo.sizes = Controller->PartitionSizes;
blksize_size[MajorNumber] = Controller->BlockSizes;
max_sectors[MajorNumber] = Controller->MaxSectorsPerRequest;
- /*
- Initialize Read Ahead to 128 sectors.
- */
- read_ahead[MajorNumber] = 128;

and others....

Not really a sight of "good interface design taste" at all.
In esp. since I'm already pointing at this since SEVERAL YEARS.
No wonder 2.4 takes ages to finish! <- If you never bite the bullet
of mistakes from the early days (becouse they just require to
go through nearly every driver).
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:41    [W:0.114 / U:1.780 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site