On Tue, Mar 08, 2005 at 07:17:31PM +1100, Nick Piggin wrote:
> Siddha, Suresh B wrote:
> > That still might not be enough. We probably need to pass push_cpu's
> > sd to move_tasks call in active_load_balance, instead of current
> > busiest_cpu's
> > sd. Just like push_cpu, we need to add one more
Siddha, Suresh B wrote:
Nick,
On Mon, Mar 07, 2005 at 07:28:23PM +1100, Nick Piggin wrote:
Siddha, Suresh B wrote:
We are resetting the nr_balance_failed to cache_nice_tries after kicking
active balancing. But can_migrate_task will succeed only if
nr_balance_failed > cache_nice_tries.
It is
Siddha, Suresh B wrote:
Nick,
On Mon, Mar 07, 2005 at 07:28:23PM +1100, Nick Piggin wrote:
Siddha, Suresh B wrote:
We are resetting the nr_balance_failed to cache_nice_tries after kicking
active balancing. But can_migrate_task will succeed only if
nr_balance_failed cache_nice_tries.
It is
On Tue, Mar 08, 2005 at 07:17:31PM +1100, Nick Piggin wrote:
Siddha, Suresh B wrote:
That still might not be enough. We probably need to pass push_cpu's
sd to move_tasks call in active_load_balance, instead of current
busiest_cpu's
sd. Just like push_cpu, we need to add one more field to
Nick,
On Mon, Mar 07, 2005 at 07:28:23PM +1100, Nick Piggin wrote:
> Siddha, Suresh B wrote:
> > We are resetting the nr_balance_failed to cache_nice_tries after kicking
> > active balancing. But can_migrate_task will succeed only if
> > nr_balance_failed > cache_nice_tries.
> >
>
> It is
Siddha, Suresh B wrote:
Nick,
On Mon, Mar 07, 2005 at 04:34:18PM +1100, Nick Piggin wrote:
Active balancing should only kick in after the prescribed number
of rebalancing failures - can_migrate_task will see this, and
will allow the balancing to take place.
We are resetting the nr_balance_failed
Nick,
On Mon, Mar 07, 2005 at 04:34:18PM +1100, Nick Piggin wrote:
> Siddha, Suresh B wrote:
>
> >
> > By code inspection, I see an issue with this patch
> > [PATCH 10/13] remove aggressive idle balancing
> >
> > Why are we removing
Nick,
On Mon, Mar 07, 2005 at 04:34:18PM +1100, Nick Piggin wrote:
Siddha, Suresh B wrote:
By code inspection, I see an issue with this patch
[PATCH 10/13] remove aggressive idle balancing
Why are we removing cpu_and_siblings_are_idle check from
active_load_balance
Siddha, Suresh B wrote:
Nick,
On Mon, Mar 07, 2005 at 04:34:18PM +1100, Nick Piggin wrote:
Active balancing should only kick in after the prescribed number
of rebalancing failures - can_migrate_task will see this, and
will allow the balancing to take place.
We are resetting the nr_balance_failed
Nick,
On Mon, Mar 07, 2005 at 07:28:23PM +1100, Nick Piggin wrote:
Siddha, Suresh B wrote:
We are resetting the nr_balance_failed to cache_nice_tries after kicking
active balancing. But can_migrate_task will succeed only if
nr_balance_failed cache_nice_tries.
It is indeed, thanks
Siddha, Suresh B wrote:
By code inspection, I see an issue with this patch
[PATCH 10/13] remove aggressive idle balancing
Why are we removing cpu_and_siblings_are_idle check from active_load_balance?
In case of SMT, we want to give prioritization to an idle package while
doing
Siddha, Suresh B wrote:
By code inspection, I see an issue with this patch
[PATCH 10/13] remove aggressive idle balancing
Why are we removing cpu_and_siblings_are_idle check from active_load_balance?
In case of SMT, we want to give prioritization to an idle package while
doing
these in isolation.
> >
>
> Oh yes, they are very scary and I guarantee they'll cause
> problems :P
By code inspection, I see an issue with this patch
[PATCH 10/13] remove aggressive idle balancing
Why are we removing cpu_and_siblings_are_idle check from active_lo
with this patch
[PATCH 10/13] remove aggressive idle balancing
Why are we removing cpu_and_siblings_are_idle check from active_load_balance?
In case of SMT, we want to give prioritization to an idle package while
doing active_load_balance(infact, active_load_balance will be kicked
mainly because
* Nick Piggin <[EMAIL PROTECTED]> wrote:
> Ingo Molnar wrote:
> >* Nick Piggin <[EMAIL PROTECTED]> wrote:
> >
> >
> >>[PATCH 6/13] no aggressive idle balancing
> >>
> >>[PATCH 8/13] generalised CPU load averaging
> >>[PA
Ingo Molnar wrote:
* Nick Piggin <[EMAIL PROTECTED]> wrote:
[PATCH 6/13] no aggressive idle balancing
[PATCH 8/13] generalised CPU load averaging
[PATCH 9/13] less affine wakups
[PATCH 10/13] remove aggressive idle balancing
they look fine, but these are the really scary ones :-) Maybe we
* Nick Piggin <[EMAIL PROTECTED]> wrote:
> [PATCH 6/13] no aggressive idle balancing
>
> [PATCH 8/13] generalised CPU load averaging
> [PATCH 9/13] less affine wakups
> [PATCH 10/13] remove aggressive idle balancing
they look fine, but these are the really scary ones
* Nick Piggin [EMAIL PROTECTED] wrote:
[PATCH 6/13] no aggressive idle balancing
[PATCH 8/13] generalised CPU load averaging
[PATCH 9/13] less affine wakups
[PATCH 10/13] remove aggressive idle balancing
they look fine, but these are the really scary ones :-) Maybe we could
do #8
Ingo Molnar wrote:
* Nick Piggin [EMAIL PROTECTED] wrote:
[PATCH 6/13] no aggressive idle balancing
[PATCH 8/13] generalised CPU load averaging
[PATCH 9/13] less affine wakups
[PATCH 10/13] remove aggressive idle balancing
they look fine, but these are the really scary ones :-) Maybe we could
do
* Nick Piggin [EMAIL PROTECTED] wrote:
Ingo Molnar wrote:
* Nick Piggin [EMAIL PROTECTED] wrote:
[PATCH 6/13] no aggressive idle balancing
[PATCH 8/13] generalised CPU load averaging
[PATCH 9/13] less affine wakups
[PATCH 10/13] remove aggressive idle balancing
they look fine
10/13
Remove the very aggressive idle stuff that has recently gone into
2.6 - it is going against the direction we are trying to go. Hopefully
we can regain performance through other methods.
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
Index: linux-2.6/include/asm-i386/topology.h
21 matches
Mail list logo