lkml.org 
[lkml]   [1999]   [Oct]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

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