/proc/1234/syscall vs /proc/1234/wchan [LWN.net]

/proc/1234/syscall vs /proc/1234/wchan

Posted Jul 31, 2008 8:23 UTC (Thu) by walles (subscriber, #954)
Parent article: 2.6.27 - the rest of the story

I've asked this before both on the kernel mailing list and in Debian's bug tracker without getting any reply, but how is the syscall file different from the wchan file?

/proc/1234/wchan has been there for ages, but seems broken AFAICT (see the linked posts).

(Log in to post comments)

/proc/1234/syscall vs /proc/1234/wchan

Posted Aug 3, 2008 21:44 UTC (Sun) by jimparis (subscriber, #38647) [Link]

I don't get zero, but on my x86_32 machine I always get "_stext". My x86_64 machine gives more reasonable values. My guess would be this option:

config SCHED_NO_NO_OMIT_FRAME_POINTER
        def_bool y
        prompt "Single-depth WCHAN output"
        depends on X86_32
        help
          Calculate simpler /proc/<PID>/wchan values. If this option
          is disabled then wchan values will recurse back to the
          caller function. This provides more accurate wchan values,
          at the expense of slightly more scheduling overhead.

          If in doubt, say "Y".

On x86_32, by default, you will get no frame pointers, so the wchan output is not particularly useful. At least, that's how I read things. See arch/x86/Kconfig, kernel/Makefile, and arch/x86_kernel/process_32.c

By the way, this quadruple(?) negative in kernel/Makefile makes my head hurt:

ifneq ($(CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER),y)

If it's not true that we're not not omitting them... AAH