lkml.org 
[lkml]   [1999]   [Mar]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: disk head scheduling
    From: R.E.Wolff@BitWizard.nl (Rogier Wolff)

Linus Torvalds wrote:
> Note that it really shouldn't be all that much work to change the actual
> ll_rw_block.c layer - all the work is really in the devices themselves
> (adding the mapping function, and making sure the SCSI layer in particular
> can live with multiple queues).

To save on the (indirect) function call, I would like to suggest:

unsigned char **queue_numbers;

queue_number = queue_numbers[major][minor];

That would require 256 bytes of storage for every major that is in use
in the system. That's two kilobytes for 8 majors in use. Acceptable
I'd say.

It is a year ago that I last made a kernel with pointer kdev_t
so I may have forgotten the details. But roughly speaking
a kdev_t is a pointer to a device struct. That device struct
starts out with a pointer to a major struct, that contains major device number,
a name string, a pointer to a function that returns a name when given a device struct,
the block/character device bit, and all that stuff that is today
in arrays indexed by major device number, like size, block size, readahead, etc.
The device struct moreover contains minor device number, and overrides
(when non-NULL) for all the major struct entries (namefn, blocksize etc).

Such was the setup, more or less.
Clearly, in such a setup each time you invent a new field it will
cost you only for the majors actually in use plus the (major,minor) pairs
actually in use.

The transformation is more or less trivial (but many hours work).
Subtleties involve worrying about the places where today a device number
is used without the block/character device bit, the use of a device number
as a pure number where no corresponding driver exists,
the memory allocation of these device structs.
(Most major structs are allocated statically in the corresponding drivers;
the device structs are often allocated dynamically.)

Maybe someone else has some spare time to start doing this again.
Last year the kernel was almost kdev_t clean, only the nfs part
freely mixed kdev_t and dev_t.

Please, if someone does this: we want a 64-bit dev_t.


Adding just a teeny bit of "policy" in a central place:

queue_number = queue_numbers[major][minor>>3];

reduces the amount of memory used by a factor of 8,

No, that is not the right kind of stuff.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

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