Messages in this thread | | | Date | Tue, 23 Mar 1999 02:43:49 +0100 (MET) | From | (Guest section DW) | Subject | Re: 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/
| |