2.6.28-rc4-mmotm1110 - you gotta be kidding me... - Kernel

This is a discussion on 2.6.28-rc4-mmotm1110 - you gotta be kidding me... - Kernel ; Somebody's been hitting the phunky pharmaceuticals in the last 4 days, because this ball-of-joy snuck into linux-next.patch sometime between -mmotm1106 and --mmotm1110. Seen in a 'make silentallconfig' Single-depth WCHAN output (SCHED_NO_NO_OMIT_FRAME_POINTER) [Y/n/?] (NEW) ? Calculate simpler /proc/ /wchan values. If ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: 2.6.28-rc4-mmotm1110 - you gotta be kidding me...

  1. 2.6.28-rc4-mmotm1110 - you gotta be kidding me...

    Somebody's been hitting the phunky pharmaceuticals in the last 4 days,
    because this ball-of-joy snuck into linux-next.patch sometime between
    -mmotm1106 and --mmotm1110.

    Seen in a 'make silentallconfig'

    Single-depth WCHAN output (SCHED_NO_NO_OMIT_FRAME_POINTER) [Y/n/?] (NEW) ?

    Calculate simpler /proc//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".

    So if I say 'y', is that a request to disable it, or enable it? And
    what exactly do I get if I vote *against* 'more accurate wchan values'?
    Do I get everybody having the same wchan pointing somewhere in the
    scheduler code, because that's where __builtin_return_address() points?

    And please - a triple negative in the Kconfig variable name? This has
    gotta be a winner for poor taste in variable naming...



    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)
    Comment: Exmh version 2.5 07/13/2001

    iD8DBQFJGPQpcC3lWbTT17ARAopSAJ0XS6rbGlYJEOT0l22zjG 4sWPOXnwCfRdGe
    9WiS0/T1LGKERGxE6mjZttM=
    =5QW/
    -----END PGP SIGNATURE-----


  2. Re: 2.6.28-rc4-mmotm1110 - you gotta be kidding me...

    On Mon, 10 Nov 2008 21:55:37 -0500 Valdis.Kletnieks@vt.edu wrote:

    > Somebody's been hitting the phunky pharmaceuticals in the last 4 days,
    > because this ball-of-joy snuck into linux-next.patch sometime between
    > -mmotm1106 and --mmotm1110.
    >
    > Seen in a 'make silentallconfig'
    >
    > Single-depth WCHAN output (SCHED_NO_NO_OMIT_FRAME_POINTER) [Y/n/?] (NEW) ?
    >
    > Calculate simpler /proc//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.


    I got lost here.

    > If in doubt, say "Y".
    >
    > So if I say 'y', is that a request to disable it, or enable it? And
    > what exactly do I get if I vote *against* 'more accurate wchan values'?
    > Do I get everybody having the same wchan pointing somewhere in the
    > scheduler code, because that's where __builtin_return_address() points?
    >
    > And please - a triple negative in the Kconfig variable name? This has
    > gotta be a winner for poor taste in variable naming...
    >


    Even if that is all sorted out, how the heck is anyone to decide
    whether or not they need this thing?

    Also, if we really really are so wishy-washy indecisive that we need to
    make the function optional, it should if at all possible be made
    runtime-configurable, not compile-time.

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

  3. Re: 2.6.28-rc4-mmotm1110 - you gotta be kidding me...

    On Mon, 10 Nov 2008 19:37:13 -0800 Andrew Morton wrote:
    >
    > On Mon, 10 Nov 2008 21:55:37 -0500 Valdis.Kletnieks@vt.edu wrote:
    >
    > > Somebody's been hitting the phunky pharmaceuticals in the last 4 days,
    > > because this ball-of-joy snuck into linux-next.patch sometime between
    > > -mmotm1106 and --mmotm1110.
    > >
    > > Seen in a 'make silentallconfig'
    > >
    > > Single-depth WCHAN output (SCHED_NO_NO_OMIT_FRAME_POINTER) [Y/n/?] (NEW) ?
    > >
    > > Calculate simpler /proc//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.

    >
    > I got lost here.
    >
    > > If in doubt, say "Y".
    > >
    > > So if I say 'y', is that a request to disable it, or enable it? And
    > > what exactly do I get if I vote *against* 'more accurate wchan values'?
    > > Do I get everybody having the same wchan pointing somewhere in the
    > > scheduler code, because that's where __builtin_return_address() points?
    > >
    > > And please - a triple negative in the Kconfig variable name? This has
    > > gotta be a winner for poor taste in variable naming...
    > >

    >
    > Even if that is all sorted out, how the heck is anyone to decide
    > whether or not they need this thing?
    >
    > Also, if we really really are so wishy-washy indecisive that we need to
    > make the function optional, it should if at all possible be made
    > runtime-configurable, not compile-time.


    This came from commit a87d091434ed2a34d647979ab12084139ee1fe41 ("x86,
    sched: enable wchan config menu item on 64-bit"). We have had
    CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER for some time on various
    architectures, this commit just made it available on x86_64 (by changing
    its dependency from X86_32 to X86).

    --
    Cheers,
    Stephen Rothwell sfr@canb.auug.org.au
    http://www.canb.auug.org.au/~sfr/

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iEYEARECAAYFAkkZEQQACgkQjjKRsyhoI8y1TwCdE/xpityLPrhe+i9Knk7PcRoO
    RIsAoL8CAlGl52VihOwaIO7dvNPZFwi1
    =iVMv
    -----END PGP SIGNATURE-----


  4. Re: 2.6.28-rc4-mmotm1110 - you gotta be kidding me...


    * Stephen Rothwell wrote:

    > This came from commit a87d091434ed2a34d647979ab12084139ee1fe41
    > ("x86, sched: enable wchan config menu item on 64-bit"). We have
    > had CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER for some time on various
    > architectures, this commit just made it available on x86_64 (by
    > changing its dependency from X86_32 to X86).


    correct. The SCHED_NO_NO name comes from ancient history. Nevertheless
    i just renamed it to CONFIG_SCHED_OMIT_FRAME_POINTER in
    tip/sched/core, and pushed out a new auto-sched-next with that rename
    in place. We can get rid of it completely once Ken's /proc//stack
    hits upstream. (as the superior replacement for wchan)

    Ingo

    ----------------->
    From ae1e9130bfb9ad55eb97ec3fb17a122b7a118f98 Mon Sep 17 00:00:00 2001
    From: Ingo Molnar
    Date: Tue, 11 Nov 2008 09:05:16 +0100
    Subject: [PATCH] sched: rename SCHED_NO_NO_OMIT_FRAME_POINTER => SCHED_OMIT_FRAME_POINTER

    Impact: cleanup, change .config option name

    We had this ugly config name for a long time for hysteric raisons.
    Rename it to a saner name.

    We still cannot get rid of it completely, until /proc//stack
    usage replaces WCHAN usage for good.

    We'll be able to do that in the v2.6.29/v2.6.30 timeframe.

    Signed-off-by: Ingo Molnar
    ---
    arch/ia64/Kconfig | 2 +-
    arch/m32r/Kconfig | 2 +-
    arch/mips/Kconfig | 2 +-
    arch/powerpc/Kconfig | 2 +-
    arch/x86/Kconfig | 2 +-
    include/asm-m32r/system.h | 2 +-
    kernel/Makefile | 2 +-
    7 files changed, 7 insertions(+), 7 deletions(-)

    diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
    index 27eec71..59d1278 100644
    --- a/arch/ia64/Kconfig
    +++ b/arch/ia64/Kconfig
    @@ -99,7 +99,7 @@ config GENERIC_IOMAP
    bool
    default y

    -config SCHED_NO_NO_OMIT_FRAME_POINTER
    +config SCHED_OMIT_FRAME_POINTER
    bool
    default y

    diff --git a/arch/m32r/Kconfig b/arch/m32r/Kconfig
    index dbaed4a..29047d5 100644
    --- a/arch/m32r/Kconfig
    +++ b/arch/m32r/Kconfig
    @@ -273,7 +273,7 @@ config GENERIC_CALIBRATE_DELAY
    bool
    default y

    -config SCHED_NO_NO_OMIT_FRAME_POINTER
    +config SCHED_OMIT_FRAME_POINTER
    bool
    default y

    diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
    index f4af967..a5255e7 100644
    --- a/arch/mips/Kconfig
    +++ b/arch/mips/Kconfig
    @@ -653,7 +653,7 @@ config GENERIC_CMOS_UPDATE
    bool
    default y

    -config SCHED_NO_NO_OMIT_FRAME_POINTER
    +config SCHED_OMIT_FRAME_POINTER
    bool
    default y

    diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
    index 525c13a..adb23ea 100644
    --- a/arch/powerpc/Kconfig
    +++ b/arch/powerpc/Kconfig
    @@ -141,7 +141,7 @@ config GENERIC_NVRAM
    bool
    default y if PPC32

    -config SCHED_NO_NO_OMIT_FRAME_POINTER
    +config SCHED_OMIT_FRAME_POINTER
    bool
    default y

    diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
    index 1d5550d..74db682 100644
    --- a/arch/x86/Kconfig
    +++ b/arch/x86/Kconfig
    @@ -364,7 +364,7 @@ config X86_RDC321X
    as R-8610-(G).
    If you don't have one of these chips, you should say N here.

    -config SCHED_NO_NO_OMIT_FRAME_POINTER
    +config SCHED_OMIT_FRAME_POINTER
    def_bool y
    prompt "Single-depth WCHAN output"
    depends on X86
    diff --git a/include/asm-m32r/system.h b/include/asm-m32r/system.h
    index 70a57c8..c980f5b 100644
    --- a/include/asm-m32r/system.h
    +++ b/include/asm-m32r/system.h
    @@ -23,7 +23,7 @@
    */

    #if defined(CONFIG_FRAME_POINTER) || \
    - !defined(CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER)
    + !defined(CONFIG_SCHED_OMIT_FRAME_POINTER)
    #define M32R_PUSH_FP " push fp\n"
    #define M32R_POP_FP " pop fp\n"
    #else
    diff --git a/kernel/Makefile b/kernel/Makefile
    index e1af039..46e67a3 100644
    --- a/kernel/Makefile
    +++ b/kernel/Makefile
    @@ -91,7 +91,7 @@ obj-$(CONFIG_FUNCTION_TRACER) += trace/
    obj-$(CONFIG_TRACING) += trace/
    obj-$(CONFIG_SMP) += sched_cpupri.o

    -ifneq ($(CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER),y)
    +ifneq ($(CONFIG_SCHED_OMIT_FRAME_POINTER),y)
    # According to Alan Modra , the -fno-omit-frame-pointer is
    # needed for x86 only. Why this used to be enabled for all architectures is beyond
    # me. I suspect most platforms don't need this, but until we know that for sure
    --
    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/

+ Reply to Thread