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
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
* Peter Zijlstra pet...@infradead.org 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
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
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
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
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
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
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
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 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 anything
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
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 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 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 to
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 that
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
do
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/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 r...@redhat.com wrote:
On 05/02/2014 02:13 AM, Mike Galbraith wrote:
On Fri, 2014-05-02 at 00:42
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/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
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
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
Hi Rik, Mike
On Fri, May 2, 2014 at 12:00 PM, Rik van Riel r...@redhat.com 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
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 r...@redhat.com 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
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 r...@redhat.com 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
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 r...@redhat.com 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 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 r...@redhat.com 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
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,
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
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
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
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
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
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
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
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
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 that
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 target
cpu
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 needs
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
designed,
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 waker
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 disabling them
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_affine
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 does allow us to
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 not this is 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, 2014-05-02 at
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
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
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
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
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 wakeup
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 that
62 matches
Mail list logo
