Re: [PATCH] Add kallsyms_lookup() result cache

From: Andi Kleen (ak_at_suse.de)
Date: 06/19/04

  • Next message: James Bottomley: "Re: DMA API issues"
    Date:	Sat, 19 Jun 2004 01:56:52 +0200
    To: Jesse Barnes <jbarnes@engr.sgi.com>
    
    

    On Fri, 18 Jun 2004 19:26:39 -0400
    Jesse Barnes <jbarnes@engr.sgi.com> wrote:

    > On Friday, June 18, 2004 6:03 pm, 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.undisclosed-recipients:;
    >
    > No, it outputs a string:
    > jbarnes@mill:~$ cat /proc/1/wchan
    > do_select

    Indeed. I looked at /proc/self/wchan, but of course that is 0 because
    the process is running.

    But there is numerical wchan anyways - just get it from /proc/*/stat
    That is what all 2.4 based tops always used. I bet they still
    have the fallback code for that around.The 2.6 change
    will just be to read the symbol table from /proc/kallsyms instead
    of from the System.map file.

    >
    > > Doing the cache in the kernel is the wrong place. This should be fixed
    > > in user space.
    >
    > Sure, but that would be a change in behavior. It's arguably the right thing
    > to do though.

    Change what behaviour? I argue that doing it in the kernel is the wrong
    thing.

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


  • Next message: James Bottomley: "Re: DMA API issues"

    Relevant Pages

    • Re: [PATCH 1/1] 2.6.14-rc3 x86: COMMAND_LINE_SIZE
      ... > bootloader writes a string of arbitary length to some memory region, ... > interface for boot loaders is required. ... load the kernel, initramfs and cmd_line_ptr to the correct place... ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-0
      ... > and see whether the lockup goes ... Which was the last -RT kernel that you tried that didnt lock up ... (there should be only one occurence of this string.) ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • [RFC] cleanup patches for strings
      ... The patches all make the same change, there's just a lot of files the ... now found in the Kernel Janitors TODO): ... The string form ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: 2.6.8-rc3-mm2
      ... Jesse Barnes wrote: ... > kernel is past paging_init at this point). ... I'd be suspecting one of the CPU scheduler patches. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: 2.6: problem with module tainting the kernel
      ... | "unsupported module, tainting kernel" ... That string is not in the kernel source code that I can see. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)