Re: More on bigger kdev_t

Martin Dalecki (dalecki@cs.net.pl)
Mon, 11 Oct 1999 00:07:26 +0200


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/