Re: [PATCH] Add kallsyms_lookup() result cache

[Brent Casavant]

On Sat, 19 Jun 2004, Andi Kleen wrote:

> On Fri, 18 Jun 2004 15:03:00 -0500
> Brent Casavant <bcasavan@xxxxxxx> 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.

> 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?

> 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.

> Doing the cache in the kernel is the wrong place. This should be fixed
> in user space.

Hard to disagree with that -- as long as we're getting an address
out of the wchan file.  But that seems to be a point of some debate. :)
I'll have to get to the bottom of that next Monday (too tired to
think straight at the moment).

> 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
used spinlocks, and the difference in performance was lost in the
noise -- meaning we could really go either way and make little
difference which style of lock was used.

Thanks,
Brent

-- 
Brent Casavant             bcasavan@xxxxxxx        Forget bright-eyed and
Operating System Engineer  http://www.sgi.com/     bushy-tailed; I'm red-
Silicon Graphics, Inc.     44.8562N 93.1355W 860F  eyed and bushy-haired.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/