RE: Delete scheduler SD_WAKE_AFFINE and SD_WAKE_BALANCE flags

From: Chen, Kenneth W (kenneth.w.chen_at_intel.com)
Date: 07/29/05

  • Next message: Jeff Garzik: "[git patch] 2.6.x libata fix" 
    To: "'Nick Piggin'" <nickpiggin@yahoo.com.au>
Date:	Thu, 28 Jul 2005 23:27:52 -0700

    Nick Piggin wrote on Thursday, July 28, 2005 7:01 PM
    > Chen, Kenneth W wrote:
    > >Well, that's exactly what I'm trying to do: make them not aggressive
    > >at all by not performing any load balance :-) The workload gets maximum
    > >benefit with zero aggressiveness.
    >
    > Unfortunately we can't forget about other workloads, and we're
    > trying to stay away from runtime tunables in the scheduler.

    This clearly outlines an issue with the implementation. Optimize for one
    type of workload has detrimental effect on another workload and vice versa.

    > If we can get performance to within a couple of tenths of a percent
    > of the zero balancing case, then that would be preferable I think.

    I won't try to compromise between the two. If you do so, we would end up
    with two half baked raw turkey. Making less aggressive load balance in the
    wake up path would probably reduce performance for the type of workload you
    quoted earlier and for db workload, we don't want any of them at all, not
    even the code to determine whether it should be balanced or not.

    Do you have an example workload you mentioned earlier that depends on
    SD_WAKE_BALANCE? I would like to experiment with it so we can move this
    forward instead of paper talk.

    - Ken

    -
    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: Jeff Garzik: "[git patch] 2.6.x libata fix"

    Relevant Pages

    • Re: [Lse-tech] [patch] sched-domain cleanups, sched-2.6.5-rc2-mm2-A3
      ... it all depends on the workload i guess, ... scales well then the threads only share data in a read-mostly manner - ... things like JVMs tend to want good balancing - they really are userspace ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: 2.6.12-rc2-mm3
      ... Otherwise the kernels seem to work fine -- no lockup unless ... installer couldn't handle it at that time. ... Workload is normal, the lockups happen with just X and Azaereus. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: swapping and the value of /proc/sys/vm/swappiness
      ... >>That is a lot of page cache. ... it's all dependant on the workload. ... I agree that tunables are a pain in the butt, but a quick fix would to be at ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH/RFC] A method for clearing out page cache
      ... > of the time for the wrong reasons), and the last thing we want to enable ... sort of "average" workload. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [sched, patch] better wake-balancing, #3
      ... Ken hasn't measured the effect of wake balancing in 2.6.13, ... Ken's workload, we can actually make it stronger. ... Without wake balancing we basically have a completely random ... In any case, more measurements are needed. ...
      (Linux-Kernel)