Ingo Molnar wrote on Friday, July 29, 2005 4:26 AM
> * Chen, Kenneth W <[EMAIL PROTECTED]> wrote:
> > To demonstrate the problem, we turned off these two flags in the cpu
> > sd domain and measured a stunning 2.15% performance gain! And
> > deleting all the code in the try_to_wake_up() pertain t
* Nick Piggin <[EMAIL PROTECTED]> wrote:
> Chen, Kenneth W wrote:
> >Nick Piggin wrote on Thursday, July 28, 2005 7:01 PM
>
> >This clearly outlines an issue with the implementation. Optimize for one
> >type of workload has detrimental effect on another workload and vice versa.
> >
>
> Yep. Th
* Chen, Kenneth W <[EMAIL PROTECTED]> wrote:
> To demonstrate the problem, we turned off these two flags in the cpu
> sd domain and measured a stunning 2.15% performance gain! And
> deleting all the code in the try_to_wake_up() pertain to load
> balancing gives us another 0.2% gain.
another
* Nick Piggin <[EMAIL PROTECTED]> wrote:
> Well, you can easily see suboptimal scheduling decisions on many
> programs with lots of interprocess communication. For example, tbench
> on a dual Xeon:
>
> processes1 2 3 4
>
> 2.6.13-rc4: 187, 183, 17
* Nick Piggin <[EMAIL PROTECTED]> wrote:
> >>processes1 2 3 4
> >>
> >>2.6.13-rc4: 187, 183, 179 260, 259, 256 340, 320, 349 504, 496, 500
> >>no wake-bal: 180, 180, 177 254, 254, 253 268, 270, 348 345, 290, 500
> >>
> >>Numbers are MB/s, hi
Ingo Molnar wrote:
* Nick Piggin <[EMAIL PROTECTED]> wrote:
processes1 2 3 4
2.6.13-rc4: 187, 183, 179 260, 259, 256 340, 320, 349 504, 496, 500
no wake-bal: 180, 180, 177 254, 254, 253 268, 270, 348 345, 290, 500
Numbers are MB/s, high
* Nick Piggin <[EMAIL PROTECTED]> wrote:
> Well, you can easily see suboptimal scheduling decisions on many
> programs with lots of interprocess communication. For example, tbench
> on a dual Xeon:
>
> processes1 2 3 4
>
> 2.6.13-rc4: 187, 183, 17
Chen, Kenneth W wrote:
Nick Piggin wrote on Thursday, July 28, 2005 7:01 PM
This clearly outlines an issue with the implementation. Optimize for one
type of workload has detrimental effect on another workload and vice versa.
Yep. That comes up fairly regularly when tuning the scheduler :(
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 a
Chen, Kenneth W wrote:
Nick Piggin wrote on Thursday, July 28, 2005 6:46 PM
I'd like to try making them less aggressive first if possible.
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 wi
Nick Piggin wrote on Thursday, July 28, 2005 6:46 PM
> I'd like to try making them less aggressive first if possible.
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.
-
T
Chen, Kenneth W wrote:
Nick Piggin wrote on Thursday, July 28, 2005 6:25 PM
Well pipes are just an example. It could be any type of communication.
What's more, even the synchronous wakeup uses the wake balancing path
(although that could be modified to only do wake balancing for synch
wakeups,
Nick Piggin wrote on Thursday, July 28, 2005 6:25 PM
> Well pipes are just an example. It could be any type of communication.
> What's more, even the synchronous wakeup uses the wake balancing path
> (although that could be modified to only do wake balancing for synch
> wakeups, I'd have to be conv
Chen, Kenneth W wrote:
Nick Piggin wrote on Thursday, July 28, 2005 4:35 PM
Wake balancing provides an opportunity to provide some input bias
into the load balancer.
For example, if you started 100 pairs of tasks which communicate
through a pipe. On a 2 CPU system without wake balancing, prob
Nick Piggin wrote on Thursday, July 28, 2005 4:35 PM
> Wake balancing provides an opportunity to provide some input bias
> into the load balancer.
>
> For example, if you started 100 pairs of tasks which communicate
> through a pipe. On a 2 CPU system without wake balancing, probably
> half of the
Chen, Kenneth W wrote:
What sort of workload needs SD_WAKE_AFFINE and SD_WAKE_BALANCE?
SD_WAKE_AFFINE are not useful in conjunction with interrupt binding.
In fact, it creates more harm than usefulness, causing detrimental
process migration and destroy process cache affinity etc. Also
SD_WAKE_BA
What sort of workload needs SD_WAKE_AFFINE and SD_WAKE_BALANCE?
SD_WAKE_AFFINE are not useful in conjunction with interrupt binding.
In fact, it creates more harm than usefulness, causing detrimental
process migration and destroy process cache affinity etc. Also
SD_WAKE_BALANCE is giving us perfor
17 matches
Mail list logo
