On 05/06/2014 04:39 PM, Peter Zijlstra wrote:
> On Tue, May 06, 2014 at 04:19:21PM -0400, Rik van Riel wrote:
>> On 05/06/2014 07:54 AM, Peter Zijlstra wrote:
>>> On Fri, May 02, 2014 at 11:19:47AM -0400, Rik van Riel wrote:
As an aside, it also looks like SD_BALANCE_WAKE is set on all domains
* Peter Zijlstra wrote:
> On Tue, May 06, 2014 at 04:20:59PM -0400, Rik van Riel wrote:
> > On 05/06/2014 09:25 AM, Peter Zijlstra wrote:
> > > On Sun, May 04, 2014 at 08:41:09AM -0400, Rik van Riel wrote:
> > >> Even on 8-node DL980 systems, the NUMA distance in the
> > >> SLIT table is less th
On 05/06/2014 04:39 PM, Peter Zijlstra wrote:
> On Tue, May 06, 2014 at 04:19:21PM -0400, Rik van Riel wrote:
>> On 05/06/2014 07:54 AM, Peter Zijlstra wrote:
>>> On Fri, May 02, 2014 at 11:19:47AM -0400, Rik van Riel wrote:
As an aside, it also looks like SD_BALANCE_WAKE is set on all domains
On Tue, May 06, 2014 at 04:20:59PM -0400, Rik van Riel wrote:
> On 05/06/2014 09:25 AM, Peter Zijlstra wrote:
> > On Sun, May 04, 2014 at 08:41:09AM -0400, Rik van Riel wrote:
> >> Even on 8-node DL980 systems, the NUMA distance in the
> >> SLIT table is less than RECLAIM_DISTANCE, and we will
> >>
On Tue, May 06, 2014 at 04:19:21PM -0400, Rik van Riel wrote:
> On 05/06/2014 07:54 AM, Peter Zijlstra wrote:
> > On Fri, May 02, 2014 at 11:19:47AM -0400, Rik van Riel wrote:
> >> As an aside, it also looks like SD_BALANCE_WAKE is set on all domains
^^^
On 05/06/2014 09:25 AM, Peter Zijlstra wrote:
> On Sun, May 04, 2014 at 08:41:09AM -0400, Rik van Riel wrote:
>> Even on 8-node DL980 systems, the NUMA distance in the
>> SLIT table is less than RECLAIM_DISTANCE, and we will
>> do wake_affine across the entire system.
>
> Yeah, so the problem is t
On 05/06/2014 07:54 AM, Peter Zijlstra wrote:
> On Fri, May 02, 2014 at 11:19:47AM -0400, Rik van Riel wrote:
>> As an aside, it also looks like SD_BALANCE_WAKE is set on all domains
>> of a NUMA system by default, so even the non-affine wakeup will end
>> up looking for the lowest load NUMA node t
On Mon, May 05, 2014 at 10:20:20AM +0530, Preeti U Murthy wrote:
> Don't you think we should go conservative on the value of
> RECLAIM_DISTANCE in arch specific code at-least? On powerpc we set it to
> 10. Besides, the git log does not tell us the basis on which this value
> was set to a default of
On Sun, May 04, 2014 at 08:41:09AM -0400, Rik van Riel wrote:
> Even on 8-node DL980 systems, the NUMA distance in the
> SLIT table is less than RECLAIM_DISTANCE, and we will
> do wake_affine across the entire system.
Yeah, so the problem is that (AFAIK) ACPI doesn't actually specify a
metric for
On Sun, May 04, 2014 at 05:14:59PM +0530, Preeti Murthy wrote:
> As far as my understanding goes, the logic in select_task_rq_fair()
> does wake_affine() or calls select_idle_sibling() only at those
> levels of sched domains where the flag SD_WAKE_AFFINE is set.
> This flag is not set at the numa d
On Fri, May 02, 2014 at 11:19:47AM -0400, Rik van Riel wrote:
> As an aside, it also looks like SD_BALANCE_WAKE is set on all domains
> of a NUMA system by default, so even the non-affine wakeup will end
> up looking for the lowest load NUMA node to start up on.
I can't find it being set on anythi
On 05/05/2014 12:50 AM, Preeti U Murthy wrote:
> Yeah now I see it. But I still feel wake_affine() and
> select_idle_sibling() are not at fault primarily because when they were
> introduced, I don't think it was foreseen that the cpu topology would
> grow to the extent it is now.
It's not about "
On 05/05/2014 10:20 AM, Preeti U Murthy wrote:
> On 05/04/2014 06:11 PM, Rik van Riel wrote:
>> On 05/04/2014 07:44 AM, Preeti Murthy wrote:
>>> Hi Rik, Mike
>>>
>>> On Fri, May 2, 2014 at 12:00 PM, Rik van Riel wrote:
On 05/02/2014 02:13 AM, Mike Galbraith wrote:
> On Fri, 2014-05-02 at
On 05/04/2014 06:11 PM, Rik van Riel wrote:
> On 05/04/2014 07:44 AM, Preeti Murthy wrote:
>> Hi Rik, Mike
>>
>> On Fri, May 2, 2014 at 12:00 PM, Rik van Riel wrote:
>>> On 05/02/2014 02:13 AM, Mike Galbraith wrote:
On Fri, 2014-05-02 at 00:42 -0400, Rik van Riel wrote:
> Whether or
On 05/04/2014 05:34 PM, Mike Galbraith wrote:
> On Sun, 2014-05-04 at 17:14 +0530, Preeti Murthy wrote:
>> Hi Rik, Mike
>>
>> On Fri, May 2, 2014 at 12:00 PM, Rik van Riel wrote:
>>> On 05/02/2014 02:13 AM, Mike Galbraith wrote:
On Fri, 2014-05-02 at 00:42 -0400, Rik van Riel wrote:
>>>
On 05/04/2014 07:44 AM, Preeti Murthy wrote:
> Hi Rik, Mike
>
> On Fri, May 2, 2014 at 12:00 PM, Rik van Riel wrote:
>> On 05/02/2014 02:13 AM, Mike Galbraith wrote:
>>> On Fri, 2014-05-02 at 00:42 -0400, Rik van Riel wrote:
>>>
Whether or not this is the right thing to do remains to be seen
On Sun, 2014-05-04 at 17:14 +0530, Preeti Murthy wrote:
> Hi Rik, Mike
>
> On Fri, May 2, 2014 at 12:00 PM, Rik van Riel wrote:
> > On 05/02/2014 02:13 AM, Mike Galbraith wrote:
> >> On Fri, 2014-05-02 at 00:42 -0400, Rik van Riel wrote:
> >>
> >>> Whether or not this is the right thing to do re
Hi Rik, Mike
On Fri, May 2, 2014 at 12:00 PM, Rik van Riel wrote:
> On 05/02/2014 02:13 AM, Mike Galbraith wrote:
>> On Fri, 2014-05-02 at 00:42 -0400, Rik van Riel wrote:
>>
>>> Whether or not this is the right thing to do remains to be seen,
>>> but it does allow us to verify whether or not the
On Fri, 2014-05-02 at 13:27 +0200, Mike Galbraith wrote:
> On Fri, 2014-05-02 at 06:56 -0400, Rik van Riel wrote:
> > On 05/02/2014 03:37 AM, Mike Galbraith wrote:
> > > On Fri, 2014-05-02 at 02:30 -0400, Rik van Riel wrote:
> > >> On 05/02/2014 02:13 AM, Mike Galbraith wrote:
> > >>> On Fri, 20
On Fri, 2014-05-02 at 06:56 -0400, Rik van Riel wrote:
> On 05/02/2014 03:37 AM, Mike Galbraith wrote:
> > On Fri, 2014-05-02 at 02:30 -0400, Rik van Riel wrote:
> >> On 05/02/2014 02:13 AM, Mike Galbraith wrote:
> >>> On Fri, 2014-05-02 at 00:42 -0400, Rik van Riel wrote:
> >>>
> Whether or
On 05/02/2014 03:37 AM, Mike Galbraith wrote:
> On Fri, 2014-05-02 at 02:30 -0400, Rik van Riel wrote:
>> On 05/02/2014 02:13 AM, Mike Galbraith wrote:
>>> On Fri, 2014-05-02 at 00:42 -0400, Rik van Riel wrote:
>>>
Whether or not this is the right thing to do remains to be seen,
but it d
On Fri, 2014-05-02 at 02:30 -0400, Rik van Riel wrote:
> On 05/02/2014 02:13 AM, Mike Galbraith wrote:
> > On Fri, 2014-05-02 at 00:42 -0400, Rik van Riel wrote:
> >
> >> Whether or not this is the right thing to do remains to be seen,
> >> but it does allow us to verify whether or not the wake_a
On 05/02/2014 02:13 AM, Mike Galbraith wrote:
> On Fri, 2014-05-02 at 00:42 -0400, Rik van Riel wrote:
>
>> Whether or not this is the right thing to do remains to be seen,
>> but it does allow us to verify whether or not the wake_affine
>> strategy of always doing affine wakeups and only disablin
On Fri, 2014-05-02 at 08:36 +0200, Mike Galbraith wrote:
> Reason why is that case was on a box where FAIR_SLEEPERS is disabled by
> default, meaning there is no such thing as wakeup preemption. Guess
> what happens when you don't have shared LLC for a fast/light wakee to
> escape to when the wak
On Fri, 2014-05-02 at 02:08 -0400, Rik van Riel wrote:
> On 05/02/2014 01:58 AM, Mike Galbraith wrote:
> > On Fri, 2014-05-02 at 07:32 +0200, Mike Galbraith wrote:
> >> On Fri, 2014-05-02 at 00:42 -0400, Rik van Riel wrote:
> >>> Currently sync wakeups from the wake_affine code cannot work as
>
On Fri, 2014-05-02 at 00:42 -0400, Rik van Riel wrote:
> Whether or not this is the right thing to do remains to be seen,
> but it does allow us to verify whether or not the wake_affine
> strategy of always doing affine wakeups and only disabling them
> in a specific circumstance is sound, or need
On 05/02/2014 01:58 AM, Mike Galbraith wrote:
> On Fri, 2014-05-02 at 07:32 +0200, Mike Galbraith wrote:
>> On Fri, 2014-05-02 at 00:42 -0400, Rik van Riel wrote:
>>> Currently sync wakeups from the wake_affine code cannot work as
>>> designed, because the task doing the sync wakeup from the targ
On Fri, 2014-05-02 at 07:32 +0200, Mike Galbraith wrote:
> On Fri, 2014-05-02 at 00:42 -0400, Rik van Riel wrote:
> > Currently sync wakeups from the wake_affine code cannot work as
> > designed, because the task doing the sync wakeup from the target
> > cpu will block its wakee from selecting th
On Fri, 2014-05-02 at 07:32 +0200, Mike Galbraith wrote:
> On Fri, 2014-05-02 at 00:42 -0400, Rik van Riel wrote:
> > Currently sync wakeups from the wake_affine code cannot work as
> > designed, because the task doing the sync wakeup from the target
> > cpu will block its wakee from selecting th
On Fri, 2014-05-02 at 00:42 -0400, Rik van Riel wrote:
> Currently sync wakeups from the wake_affine code cannot work as
> designed, because the task doing the sync wakeup from the target
> cpu will block its wakee from selecting that cpu.
>
> This is despite the fact that whether or not the wake
Currently sync wakeups from the wake_affine code cannot work as
designed, because the task doing the sync wakeup from the target
cpu will block its wakee from selecting that cpu.
This is despite the fact that whether or not the wakeup is sync
determines whether or not we want to do an affine wakeu
31 matches
Mail list logo
