Re: [patch] sched: auto-tune migration costs [was: Re: Industry db benchmark result on recent 2.6 kernels]

From: Ingo Molnar (mingo_at_elte.hu)
Date: 04/03/05

  • Next message: David Lang: "Re: Industry db benchmark result on recent 2.6 kernels" 
    Date:	Sun, 3 Apr 2005 09:04:16 +0200
To: Paul Jackson <pj@engr.sgi.com>

    * Paul Jackson <pj@engr.sgi.com> wrote:

    > Just so as no else wastes time repeating the little bit I've done so
    > far, and so I don't waste time figuring out what is already known,
    > here's what I have so far, trying out Ingo's "sched: auto-tune
    > migration costs" on ia64 SN2:
    >
    > To get it to compile against 2.6.12-rc1-mm4, I did thus:
    >
    > 1. Manually edited "include/asm-x86_64/topology.h" to
    > remove .cache_hot_time (patch failed due to conflicts
    > with nearby changes to add some *_idx terms).

    (next time you can ignore that hunk - we override the cache_hot_time
    value anyway.)

    > 2. Moved the 394 line block of new code in kernel/sched.c
    > to _before_ the large #ifdef ARCH_HAS_SCHED_DOMAIN,
    > #else, #endif block. The ia64 arch (only) defines
    > ARCH_HAS_SCHED_DOMAIN, so was being denied use of Ingo's
    > code when it was buried in the '#else-#endif' side of
    > this large conditional block.

    yeah, indeed. The place you moved it to is the right spot, as it's under
    CONFIG_SMP. I've done this in my tree too.

    > 3. Add "#include <linux/vmalloc.h>" to kernel/sched.c

    ok, did this in my tree too.

    > 4. Don't print cpu_khz in the cost matrix header, as cpu_khz
    > is only in a few arch's (x86_64, ppc, i386, arm).

    ok.

    > Brought up 8 CPUs
    > softlockup thread 7 started up.
    > Total of 8 processors activated (15548.60 BogoMIPS).
    > ---------------------
    > migration cost matrix (max_cache_size: 33554432):
    > ---------------------
    > [00] [01] [02] [03] [04] [05] [06] [07]
    > [00]: -
    > ============================= end =============================
    >
    > Then it hung for 5 or 10 minutes, [...]

    the default on ia64 (32MB) was way too large and caused the search to
    start from 64MB. That can take a _long_ time.

    i've attached a new patch with your changes included, and a couple of
    new things added:

     - removed the 32MB max_cache_size hack from ia64 - it should now fall
       back to the default 5MB and do a search from 10MB downwards. This
       should speed up the search.

     - added a migration_debug boot option - use it to get verbose printouts
       about the search for the migration cost.

     - added a max_cache_size=<bytes> boot option for debugging.

     - a few cleanups

    (in the next iteration of the patch i'll try a new method to further
    speed up the search - but didnt want to change it too much in this
    iteration.)

    > [<a0000001000db0d0>] schedule_work+0x30/0x60
    > sp=e00001b03a8d7910 bsp=e00001b03a8d14c8
    > [<a000000100490230>] blank_screen_t+0x30/0x60
    > sp=e00001b03a8d7910 bsp=e00001b03a8d14b8
    > [<a0000001000c8130>] run_timer_softirq+0x2d0/0x4a0
    > sp=e00001b03a8d7910 bsp=e00001b03a8d1410

    i think the crash is an unrelated bug: it seems the screen blanking
    timer hit and has crashed the box - i suspect it didnt expect the bootup
    to take that long.

            Ingo

    -
    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: David Lang: "Re: Industry db benchmark result on recent 2.6 kernels"

    Relevant Pages
    Loading