Re: [PATCH] Add kallsyms_lookup() result cache

[Andi Kleen <ak@suse.de>]

On Fri, 18 Jun 2004 18:31:27 -0500
Brent Casavant <bcasavan@sgi.com> wrote:

> On Sat, 19 Jun 2004, Andi Kleen wrote:
> 
> > On Fri, 18 Jun 2004 15:03:00 -0500
> > Brent Casavant <bcasavan@sgi.com> wrote:
> >
> > > On 2.6 based systems, the top command utilizes /proc/[pid]/wchan to
> > > determine WCHAN symbol name information.  This information is provided
> > > by the kernel function kallsyms_lookup(), which expands a stem-compressed
> >
> > That sounds more like a bug in your top to me. /proc/*/wchan itself
> > does not access kallsyms, it just outputs a number.
> 
> Strange.  All the 2.6 boxes I have access to output a symbol name.
> I've checked on Debian, SLES9, and Fedora Core 2.  It's not
> impossible that I have the same whacked-out configuration on all of
> them, but they definitely output symbol names, not just numbers.

Yes, that was my mistake. I looked at /proc/self/wchan, which is 
probably the only one who outputs a number ...

But anyways you can get the number from /proc/*/stat like in 2.4

> 
> > My top doesn't do that.
> 
> Hmm.  procps version 3.1.3 introduced the use of /proc/*/wchan where
> possible.  I'm using 2.0.13 normally, which appears to have the same
> behavior (can't find a changelong for the 2 series at the moment).
> Is it your recommendation that I take this up with the maintainers of
> procps?

Yes. Let them revert to the 2.4 code again, only change that they
should read /proc/kallsyms instead of /boot/System.map


> 
> > Are you saying your top reads /proc/kallsyms on each redisplay?
> > That sounds completely wrong - it should only read the file once
> > and cache it and then look the numbers it is reading from wchan
> > in the cache.
> 
> It would appear so from the performance improvements I observed upon
> implementing this cache.

I straced a fairly recent SUSE top and it didn't access wchan
in normal operation. 

> 
> > As an unrelated comment: i would suggest to avoid rwlocks until
> > absolutely needed. They are a lot slower than regular spinlocks.
> 
> The lock isn't very highly contended at all, and assuming the cache
> hits almost all of the time, the rwlock seemed better as it would
> cause the minimum amount of waiting.  That said, my first implementation

When it starts to get contended the read locks tend to be slower
because they have to bounce more cache lines around.

-Andi