On Tue, Apr 25, 2017 at 9:13 AM, Doug Smythies wrote:
> On 2017.04.24 07:25 Doug wrote:
>> On 2017.04.23 18:23 Srinivas Pandruvada wrote:
>>> On Mon, 2017-04-24 at 02:59 +0200, Rafael J. Wysocki wrote:
On Sun, Apr 23, 2017 at 5:31 PM, Doug Smythies wrote:
>>
> It looks like the cost is m
Hi Rafael,
Apologies, I reversed reported a couple of data points last night:
On 2017.04.25 00:13 Doug wrote:
> On 2017.04.24 07:25 Doug wrote:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git linux-next
>> Plus that patch is in progress.
>
>3387.76 Seconds.
> Idle power 3.
On 2017.04.24 07:25 Doug wrote:
> On 2017.04.23 18:23 Srinivas Pandruvada wrote:
>> On Mon, 2017-04-24 at 02:59 +0200, Rafael J. Wysocki wrote:
>>> On Sun, Apr 23, 2017 at 5:31 PM, Doug Smythies wrote:
>
It looks like the cost is mostly related to moving the load from
one CPU to
ano
On 2017.04.23 18:23 Srinivas Pandruvada wrote:
> On Mon, 2017-04-24 at 02:59 +0200, Rafael J. Wysocki wrote:
>> On Sun, Apr 23, 2017 at 5:31 PM, Doug Smythies wrote:
>>> It looks like the cost is mostly related to moving the load from
>>> one CPU to
>>> another and waiting for the new one to ramp
On Sat, Apr 22, 2017 at 11:07:44PM +0200, Rafael J. Wysocki wrote:
> > By far, and with any code, I get the fastest elapsed time, of course next
> > to performance mode, but not by much, by limiting the test to only use
> > just 1 cpu: 1814.2 Seconds.
>
> Interesting.
>
> It looks like the cost i
On Mon, 2017-04-24 at 02:59 +0200, Rafael J. Wysocki wrote:
> On Sun, Apr 23, 2017 at 5:31 PM, Doug Smythies
> wrote:
[...]
> > It looks like the cost is mostly related to moving the load from
> > > one CPU to
> > > another and waiting for the new one to ramp up then.
Last time when we analyzed M
On Sun, Apr 23, 2017 at 5:31 PM, Doug Smythies wrote:
> On 2017.04.22 14:08 Rafael wrote:
>> On Friday, April 21, 2017 11:29:06 PM Doug Smythies wrote:
>>> On 2017.04.20 18:18 Rafael wrote:
On Thursday, April 20, 2017 07:55:57 AM Doug Smythies wrote:
> On 2017.04.19 01:16 Mel Gorman wrote
On 2017.04.22 14:08 Rafael wrote:
> On Friday, April 21, 2017 11:29:06 PM Doug Smythies wrote:
>> On 2017.04.20 18:18 Rafael wrote:
>>> On Thursday, April 20, 2017 07:55:57 AM Doug Smythies wrote:
On 2017.04.19 01:16 Mel Gorman wrote:
> On Fri, Apr 14, 2017 at 04:01:40PM -0700, Doug Smythi
On Friday, April 21, 2017 11:29:06 PM Doug Smythies wrote:
> On 2017.04.20 18:18 Rafael wrote:
> > On Thursday, April 20, 2017 07:55:57 AM Doug Smythies wrote:
> >> On 2017.04.19 01:16 Mel Gorman wrote:
> >>> On Fri, Apr 14, 2017 at 04:01:40PM -0700, Doug Smythies wrote:
> Hi Mel,
> >
> > [cut
On 2017.04.20 18:18 Rafael wrote:
> On Thursday, April 20, 2017 07:55:57 AM Doug Smythies wrote:
>> On 2017.04.19 01:16 Mel Gorman wrote:
>>> On Fri, Apr 14, 2017 at 04:01:40PM -0700, Doug Smythies wrote:
Hi Mel,
>
> [cut]
>
>>> And the revert does help albeit not being an option for reasons R
On Thursday, April 20, 2017 07:55:57 AM Doug Smythies wrote:
> On 2017.04.19 01:16 Mel Gorman wrote:
> > On Fri, Apr 14, 2017 at 04:01:40PM -0700, Doug Smythies wrote:
> >> Hi Mel,
[cut]
> > And the revert does help albeit not being an option for reasons Rafael
> > covered.
>
> New data point: K
On Wednesday, April 19, 2017 09:15:37 AM Mel Gorman wrote:
> On Fri, Apr 14, 2017 at 04:01:40PM -0700, Doug Smythies wrote:
> > Hi Mel,
> >
> > Thanks for the "how to" information.
> > This is a very interesting use case.
> > From trace data, I see a lot of minimal durations with
> > virtually no
On Tuesday, April 11, 2017 11:02:34 AM Mel Gorman wrote:
> On Mon, Apr 10, 2017 at 10:51:38PM +0200, Rafael J. Wysocki wrote:
> > Hi Mel,
> >
> > On Mon, Apr 10, 2017 at 10:41 AM, Mel Gorman
> > wrote:
> > > Hi Rafael,
> > >
> > > Since kernel 4.6, performance of the low CPU intensity workloads w
On 2017.04.19 01:16 Mel Gorman wrote:
> On Fri, Apr 14, 2017 at 04:01:40PM -0700, Doug Smythies wrote:
>> Hi Mel,
>>
>> Thanks for the "how to" information.
>> This is a very interesting use case.
>> From trace data, I see a lot of minimal durations with
>> virtually no load on the CPU, typically
On Fri, Apr 14, 2017 at 04:01:40PM -0700, Doug Smythies wrote:
> Hi Mel,
>
> Thanks for the "how to" information.
> This is a very interesting use case.
> From trace data, I see a lot of minimal durations with
> virtually no load on the CPU, typically more consistent
> with some type of light duty
Hi Mel,
Thanks for the "how to" information.
This is a very interesting use case.
>From trace data, I see a lot of minimal durations with
virtually no load on the CPU, typically more consistent
with some type of light duty periodic (~~100 Hz) work flow
(where we would prefer to not ramp up frequen
On Tue, Apr 11, 2017 at 08:41:09AM -0700, Doug Smythies wrote:
> On 2017.04.11 03:03 Mel Gorman wrote:
> >On Mon, Apr 10, 2017 at 10:51:38PM +0200, Rafael J. Wysocki wrote:
> >> On Mon, Apr 10, 2017 at 10:41 AM, Mel Gorman wrote:
> >>>
> >>> It's far more obvious when looking at the git test suite
On 2017.04.11 03:03 Mel Gorman wrote:
>On Mon, Apr 10, 2017 at 10:51:38PM +0200, Rafael J. Wysocki wrote:
>> On Mon, Apr 10, 2017 at 10:41 AM, Mel Gorman wrote:
>>>
>>> It's far more obvious when looking at the git test suite and the length
>>> of time it takes to run. This is a shellscript and git
On Mon, Apr 10, 2017 at 10:51:38PM +0200, Rafael J. Wysocki wrote:
> Hi Mel,
>
> On Mon, Apr 10, 2017 at 10:41 AM, Mel Gorman
> wrote:
> > Hi Rafael,
> >
> > Since kernel 4.6, performance of the low CPU intensity workloads was dropped
> > severely. netperf UDP_STREAM has about 15-20% CPU utilisa
Hi Mel,
On Mon, Apr 10, 2017 at 10:41 AM, Mel Gorman
wrote:
> Hi Rafael,
>
> Since kernel 4.6, performance of the low CPU intensity workloads was dropped
> severely. netperf UDP_STREAM has about 15-20% CPU utilisation has regressed
> about 10% relative to 4.4 anad about 6-9% running TCP_STREAM.
20 matches
Mail list logo
