lkml.org 
[lkml]   [2003]   [Apr]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] HT scheduler, sched-2.5.68-B2
>>> >  - turn off the more agressive idle-steal variant. This could fix the
>>> > low-load regression reported by Martin J. Bligh.
>>>
>>> Yup, that fixed it (I tested just your first version with just that
>>> bit altered).
>>
>> Can we make this an arch specific option? I have a feeling the HT performance
>> on low loads will actually drop with this disabled.

Actually, what must be happening here is that we're agressively stealing
things on non-HT machines ... we should be able to easily prevent that.

Suppose we have 2 real cpus + HT ... A,B,C,D are the cpus, where A, B
are HT twins, and C,D are HT twins. A&B share runqueue X, and C&D share
runqueue Y

What I presume you're trying to do is when A and B are running 1 task
each, and C and D are not running anything, balance out so we have
one on A and one on C. If we define some "nr_active(rq)" concept to be
the number of tasks actually actively running on cpus, then if we we're
switching from nr_actives of 2/0 to 1/0.

However, we don't want to switch from 2/1 to 1/2 ... that's pointless.
Or 0/1 to 1/0 (which I think it's what's happening). But in the case
where we had (theoretically) 4 HT siblings per real cpu, we would want
to migrate 1/3 to 2/2.

The key is that we want to agressively steal when
nr_active(remote) - nr_active(idle) > 1 ... not > 0.
This will implicitly *never* happen on non HT machines, so it seems
like a nice algorithm ... ?
M.

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:34    [from the cache]
©2003-2011 Jasper Spaans