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
ahead
values... so you don't see the impact of this DAMN interface in
benchmarks.
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
times.
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 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