Lock granularity...

[Michel W Zappe]

Right now i've mostly noticed the kernel lock's while perusing the code.  I
haven't focused too much of my attention on those locks in particular, since
my real bottleneck is in bdflush.  I was just wondering if there were any
projects looking at that.  Some of the places i've looked also appear to be
inopportune places, such as the nfs client code, all over the namei routines,
the IPv4 stack, UNIX domain sockets, etc.  Unfortunately, alot of pre-packaged
benchmarks look at subsystems independantly, and they are not comprehensive
measure of overall system performance.  With the interaction of all of these
on an SMP application server, however, it's probably causing ALOT of unneeded
waits.
What a co-worker and i had in mind, specifically, was to come up with a site
documenting all of the global kernel locks aquired in the kernel, and a place
to discuss why they're there, and ways to increase the granularity of the
locks.  That would probably help linux along to having better SMP performace,
by leaps and bounds.  So, what do you guy's think of this idea?

    Michael

Mark Hahn wrote:

> > While i've been working with the linux kernel, i've noticed some definate
> > performance bottlenecks in its implementation,
>
> do you mean "noticed" in the sense of "this benchmark runs slow",
> or just in the sense of inspecting the code?  Linux is far more
> motivated by demonstrable hotspots, rather than the mere fact
> that one lock is used a lot...
>
> thanks, mark hahn.


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