On 8 December 2016 at 15:09, Matt Fleming wrote:
> On Mon, 05 Dec, at 01:35:46PM, Matt Fleming wrote:
>> On Mon, 05 Dec, at 10:27:36AM, Vincent Guittot wrote:
>> >
>> > Hi Matt,
>> >
>> > Thanks for the results.
>> >
>> > During the review, it has been pointed out by
On 8 December 2016 at 15:09, Matt Fleming wrote:
> On Mon, 05 Dec, at 01:35:46PM, Matt Fleming wrote:
>> On Mon, 05 Dec, at 10:27:36AM, Vincent Guittot wrote:
>> >
>> > Hi Matt,
>> >
>> > Thanks for the results.
>> >
>> > During the review, it has been pointed out by Morten that the test
>> >
On Mon, 05 Dec, at 01:35:46PM, Matt Fleming wrote:
> On Mon, 05 Dec, at 10:27:36AM, Vincent Guittot wrote:
> >
> > Hi Matt,
> >
> > Thanks for the results.
> >
> > During the review, it has been pointed out by Morten that the test condition
> > (100*this_avg_load < imbalance_scale*min_avg_load)
On Mon, 05 Dec, at 01:35:46PM, Matt Fleming wrote:
> On Mon, 05 Dec, at 10:27:36AM, Vincent Guittot wrote:
> >
> > Hi Matt,
> >
> > Thanks for the results.
> >
> > During the review, it has been pointed out by Morten that the test condition
> > (100*this_avg_load < imbalance_scale*min_avg_load)
On Mon, 05 Dec, at 10:27:36AM, Vincent Guittot wrote:
>
> Hi Matt,
>
> Thanks for the results.
>
> During the review, it has been pointed out by Morten that the test condition
> (100*this_avg_load < imbalance_scale*min_avg_load) makes more sense than
> (100*min_avg_load >
On Mon, 05 Dec, at 10:27:36AM, Vincent Guittot wrote:
>
> Hi Matt,
>
> Thanks for the results.
>
> During the review, it has been pointed out by Morten that the test condition
> (100*this_avg_load < imbalance_scale*min_avg_load) makes more sense than
> (100*min_avg_load >
Le Saturday 03 Dec 2016 à 21:47:07 (+), Matt Fleming a écrit :
> On Fri, 02 Dec, at 07:31:04PM, Brendan Gregg wrote:
> >
> > For background, is this from the "A decade of wasted cores" paper's
> > patches?
>
> No, this patch fixes an issue I originally reported here,
>
>
Le Saturday 03 Dec 2016 à 21:47:07 (+), Matt Fleming a écrit :
> On Fri, 02 Dec, at 07:31:04PM, Brendan Gregg wrote:
> >
> > For background, is this from the "A decade of wasted cores" paper's
> > patches?
>
> No, this patch fixes an issue I originally reported here,
>
>
On Fri, 02 Dec, at 07:31:04PM, Brendan Gregg wrote:
>
> For background, is this from the "A decade of wasted cores" paper's
> patches?
No, this patch fixes an issue I originally reported here,
https://lkml.kernel.org/r/20160923115808.2330-1-m...@codeblueprint.co.uk
Essentially, if you have
On Fri, 02 Dec, at 07:31:04PM, Brendan Gregg wrote:
>
> For background, is this from the "A decade of wasted cores" paper's
> patches?
No, this patch fixes an issue I originally reported here,
https://lkml.kernel.org/r/20160923115808.2330-1-m...@codeblueprint.co.uk
Essentially, if you have
On Fri, Nov 25, 2016 at 7:34 AM, Vincent Guittot
wrote:
>
> find_idlest_group() only compares the runnable_load_avg when looking for
> the least loaded group. But on fork intensive use case like hackbench
> where tasks blocked quickly after the fork, this can lead to
On Fri, Nov 25, 2016 at 7:34 AM, Vincent Guittot
wrote:
>
> find_idlest_group() only compares the runnable_load_avg when looking for
> the least loaded group. But on fork intensive use case like hackbench
> where tasks blocked quickly after the fork, this can lead to selecting the
> same CPU
On Fri, 02 Dec, at 04:20:54PM, Vincent Guittot wrote:
>
> Matt,
>
> Have you been able to get some results for the patchset ?
Sorry, I messed up the test config and the tests never ran :(
I've redone everything and fast-tracked the results on the SUSE grid
now. Should have results by morning.
On Fri, 02 Dec, at 04:20:54PM, Vincent Guittot wrote:
>
> Matt,
>
> Have you been able to get some results for the patchset ?
Sorry, I messed up the test config and the tests never ran :(
I've redone everything and fast-tracked the results on the SUSE grid
now. Should have results by morning.
On 30 November 2016 at 15:24, Morten Rasmussen wrote:
> On Wed, Nov 30, 2016 at 02:54:00PM +0100, Vincent Guittot wrote:
>> On 30 November 2016 at 14:49, Vincent Guittot
>> wrote:
>> > On 30 November 2016 at 13:49, Morten Rasmussen
On 30 November 2016 at 15:24, Morten Rasmussen wrote:
> On Wed, Nov 30, 2016 at 02:54:00PM +0100, Vincent Guittot wrote:
>> On 30 November 2016 at 14:49, Vincent Guittot
>> wrote:
>> > On 30 November 2016 at 13:49, Morten Rasmussen
>> > wrote:
>> >> On Fri, Nov 25, 2016 at 04:34:33PM +0100,
On Wed, Nov 30, 2016 at 02:54:00PM +0100, Vincent Guittot wrote:
> On 30 November 2016 at 14:49, Vincent Guittot
> wrote:
> > On 30 November 2016 at 13:49, Morten Rasmussen
> > wrote:
> >> On Fri, Nov 25, 2016 at 04:34:33PM +0100, Vincent
On Wed, Nov 30, 2016 at 02:54:00PM +0100, Vincent Guittot wrote:
> On 30 November 2016 at 14:49, Vincent Guittot
> wrote:
> > On 30 November 2016 at 13:49, Morten Rasmussen
> > wrote:
> >> On Fri, Nov 25, 2016 at 04:34:33PM +0100, Vincent Guittot wrote:
> >>> find_idlest_group() only compares
On Wed, Nov 30, 2016 at 02:49:11PM +0100, Vincent Guittot wrote:
> On 30 November 2016 at 13:49, Morten Rasmussen
> wrote:
> > On Fri, Nov 25, 2016 at 04:34:33PM +0100, Vincent Guittot wrote:
> >> find_idlest_group() only compares the runnable_load_avg when looking for
On Wed, Nov 30, 2016 at 02:49:11PM +0100, Vincent Guittot wrote:
> On 30 November 2016 at 13:49, Morten Rasmussen
> wrote:
> > On Fri, Nov 25, 2016 at 04:34:33PM +0100, Vincent Guittot wrote:
> >> find_idlest_group() only compares the runnable_load_avg when looking for
> >> the least loaded
On 30 November 2016 at 14:49, Vincent Guittot
wrote:
> On 30 November 2016 at 13:49, Morten Rasmussen
> wrote:
>> On Fri, Nov 25, 2016 at 04:34:33PM +0100, Vincent Guittot wrote:
>>> find_idlest_group() only compares the runnable_load_avg
On 30 November 2016 at 14:49, Vincent Guittot
wrote:
> On 30 November 2016 at 13:49, Morten Rasmussen
> wrote:
>> On Fri, Nov 25, 2016 at 04:34:33PM +0100, Vincent Guittot wrote:
>>> find_idlest_group() only compares the runnable_load_avg when looking for
>>> the least loaded group. But on fork
On 30 November 2016 at 13:49, Morten Rasmussen wrote:
> On Fri, Nov 25, 2016 at 04:34:33PM +0100, Vincent Guittot wrote:
>> find_idlest_group() only compares the runnable_load_avg when looking for
>> the least loaded group. But on fork intensive use case like hackbench
On 30 November 2016 at 13:49, Morten Rasmussen wrote:
> On Fri, Nov 25, 2016 at 04:34:33PM +0100, Vincent Guittot wrote:
>> find_idlest_group() only compares the runnable_load_avg when looking for
>> the least loaded group. But on fork intensive use case like hackbench
[snip]
>> +
On Fri, Nov 25, 2016 at 04:34:33PM +0100, Vincent Guittot wrote:
> find_idlest_group() only compares the runnable_load_avg when looking for
> the least loaded group. But on fork intensive use case like hackbench
> where tasks blocked quickly after the fork, this can lead to selecting the
> same
On Fri, Nov 25, 2016 at 04:34:33PM +0100, Vincent Guittot wrote:
> find_idlest_group() only compares the runnable_load_avg when looking for
> the least loaded group. But on fork intensive use case like hackbench
> where tasks blocked quickly after the fork, this can lead to selecting the
> same
find_idlest_group() only compares the runnable_load_avg when looking for
the least loaded group. But on fork intensive use case like hackbench
where tasks blocked quickly after the fork, this can lead to selecting the
same CPU instead of other CPUs, which have similar runnable load but a
lower
find_idlest_group() only compares the runnable_load_avg when looking for
the least loaded group. But on fork intensive use case like hackbench
where tasks blocked quickly after the fork, this can lead to selecting the
same CPU instead of other CPUs, which have similar runnable load but a
lower
28 matches
Mail list logo