Messages in this thread | | | Date | Mon, 11 Oct 1999 00:07:26 +0200 | From | Martin Dalecki <> | Subject | Re: More on bigger kdev_t |
| |
Jeff Garzik wrote: > > Martin Dalecki wrote: > > I have tryed the direct approach to kdev_t several years ago out. > > The lost in speed caused by introducing the strcut was really noticable > > in the overall device system's performance. > > > > It was about scary several percents. Sorry I'm not quite > > sure if my memmory leaves me, but it was about as much as 3% on a > > 486/66MHz (Yes It was that long ago...) > > And this after only folding the arrays indexed by MINOR(dev) into a > > single > > array of corresponding structs. > > Just to be clear, you replaced kdev_t with a struct, or a ptr to a > struct? > > And what did you do with the arrays indexed by MINOR(dev)? Andries > pointed out that a linear search for a major/minor could be ugly and > slow, potentially causing the slowdown you mention.
In fact I didn't even get as far as changing kdev_t itself. I have just introduced and used it to melt the few arrays, which are indexed through MINRO(dev) into a single array of structs. Thus I have approached the problem from the bottom, instead of top down... But this is something anybody serious about it will do anyway :-).
This action was already sufficient for the impact on performance I saw. (I tested it basically by using hdparm -[tT] /dev/hdxx).
I hope it's clear now?
--Marcin
- 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/
| |