Re: [Lse-tech] [patch] sched-domain cleanups, sched-2.6.5-rc2-mm2-A3

From: Nick Piggin (nickpiggin_at_yahoo.com.au)
Date: 03/30/04

  • Next message: Ingo Molnar: "Re: [Lse-tech] [patch] sched-domain cleanups, sched-2.6.5-rc2-mm2-A3" 
    Date: 	Tue, 30 Mar 2004 18:53:58 +1000
To: Ingo Molnar <mingo@elte.hu>

    Ingo Molnar wrote:
    > * Nick Piggin <nickpiggin@yahoo.com.au> wrote:
    >
    >
    >>You're probably mostly right, but I really don't know if I'd start
    >>with the assumption that threads don't share anything. I think they're
    >>very likely to share memory and cache.
    >
    >
    > it all depends on the workload i guess, but generally if the application
    > scales well then the threads only share data in a read-mostly manner -
    > hence we can balance at creation time.
    >
    > if the application does not scale well then balancing too early cannot
    > make the app perform much worse.
    >
    > things like JVMs tend to want good balancing - they really are userspace
    > simulations of separate contexts with little sharing and good overall
    > scalability of the architecture.
    >

    Well, it will be interesting to see how it goes. Unfortunately
    I don't have a single realistic benchmark. In fact the only
    threaded one I have is volanomark.

    >
    >>Also, these additional system wide balance points don't come for free
    >>if you attach them to common operations (as opposed to the slow
    >>periodic balancing).
    >
    >
    > yes, definitely.
    >
    > the implementation in sched2.patch does not take this into account yet.
    > There are a number of things we can do about the 500 CPUs case. Eg. only
    > do the balance search towards the next N nodes/cpus (tunable via a
    > domain parameter).

    Yeah I think we shouldn't worry too much about the 500 CPUs
    case, because they will obviously end up using their own
    domains. But it is possible this would hurt smaller CPU
    counts too. Again, it means testing.

    I think we should probably aim to have a usable and decent
    default domain for 32, maybe 64 CPUs, and not worry about
    larger numbers too much if it would hurt lower end performance.
    -
    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: Ingo Molnar: "Re: [Lse-tech] [patch] sched-domain cleanups, sched-2.6.5-rc2-mm2-A3"

    Relevant Pages

    • Re: [Lse-tech] Re: [patch] scheduler fix for 1cpu/node case
      ... >> Even with this patch it still seems that most balances are still timer ... >> advantage of doing this at idle, but idle only, that's why I'd would be ... > don't have multiple steals per balance attempt. ... to limit the range of cpus to find a busiest queue. ...
      (Linux-Kernel)
    • Re: VST and Sched Load Balance
      ... > scheduler load balance. ... since the idle CPUs will no longer pull tasks from ...
      (Linux-Kernel)
    • VST and Sched Load Balance
      ... regular timer ticks when a CPU is idle. ... scheduler load balance. ... since the idle CPUs will no longer pull tasks from ... +#endif + do {unsigned long load; int local_group; ...
      (Linux-Kernel)
    • Re: [Lse-tech] [patch] sched-domain cleanups, sched-2.6.5-rc2-mm2-A3
      ... >>Maybe balance on clone would be beneficial if we only balance onto ... >>CPUs which are idle or very very imbalanced. ... >>better to do it at clone. ... But the scheduler ...
      (Linux-Kernel)
    • [patch] scheduler: rebalance_tick interval update
      ... jiffies after a load_balance, then the meaning of last_balance is more ... handled the balance we were supposed to do at 20, ... /* We've pulled tasks over so no longer idle */ ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)