Hi, Peter
Davidlohr has tested the v3 patch set and it work well as reported (and
in my test too), I thing your patch has solved the issue he found in v2 :)
Thus I think v3 is ready for next step now, I wish it has not yet been
removed out of your apply-queue ;-)
Regards,
Michael Wang
On 07/15/
On 07/15/2013 01:57 PM, Davidlohr Bueso wrote:
[snip]
>>>
>>> And if it is possible, comparison based on the same basement will be
>>> better :)
>>
>> I have done some tests with reaim high_systime workfile, and I could not
>> find regression on my box (the tool itself has some issue, but I got the
On Mon, 2013-07-15 at 13:13 +0800, Michael Wang wrote:
> Hi, Davidlohr
>
> On 07/09/2013 10:52 AM, Michael Wang wrote:
> > On 07/09/2013 10:36 AM, Davidlohr Bueso wrote:
> > [snip]
> >>> 2. is the 3.10-rc5 in image also disabled the hyperthreading?
> >>
> >> Yes, I happened to have data already co
Hi, Davidlohr
On 07/09/2013 10:52 AM, Michael Wang wrote:
> On 07/09/2013 10:36 AM, Davidlohr Bueso wrote:
> [snip]
>>> 2. is the 3.10-rc5 in image also disabled the hyperthreading?
>>
>> Yes, I happened to have data already collected for 3.10-rc5. While the
>> runs with this patch was with -rc7,
On 07/09/2013 10:36 AM, Davidlohr Bueso wrote:
[snip]
>> 2. is the 3.10-rc5 in image also disabled the hyperthreading?
>
> Yes, I happened to have data already collected for 3.10-rc5. While the
> runs with this patch was with -rc7, unless there was some performance
> related commit I missed, I don
On Tue, 2013-07-09 at 10:30 +0800, Michael Wang wrote:
> Hi, Davidlohr
>
> Thanks for the testing :)
>
> On 07/09/2013 02:59 AM, Davidlohr Bueso wrote:
> [snip]
> >>
> >> OK, I'll apply the patches, we'll see what happens. If there significant
> >> fallout we'll immediately have more information
Hi, Davidlohr
Thanks for the testing :)
On 07/09/2013 02:59 AM, Davidlohr Bueso wrote:
[snip]
>>
>> OK, I'll apply the patches, we'll see what happens. If there significant
>> fallout we'll immediately have more information anyway ;-)
>
> So I gave the v2 a spin on my aim7 benchmark on an 80-cor
On 07/08/2013 04:49 PM, Mike Galbraith wrote:
> On Mon, 2013-07-08 at 10:21 +0200, Peter Zijlstra wrote:
>> On Sun, Jul 07, 2013 at 08:43:25AM +0200, Mike Galbraith wrote:
>>> On Fri, 2013-07-05 at 14:16 +0800, Michael Wang wrote:
>>>
PeterZ has suggested some optimization which I sent out ye
On 07/08/2013 04:21 PM, Peter Zijlstra wrote:
> On Sun, Jul 07, 2013 at 08:43:25AM +0200, Mike Galbraith wrote:
>> On Fri, 2013-07-05 at 14:16 +0800, Michael Wang wrote:
>>
>>> PeterZ has suggested some optimization which I sent out yesterday, I
>>> suppose they haven't been included into this test
On Mon, 2013-07-08 at 10:21 +0200, Peter Zijlstra wrote:
> On Sun, Jul 07, 2013 at 08:43:25AM +0200, Mike Galbraith wrote:
> > On Fri, 2013-07-05 at 14:16 +0800, Michael Wang wrote:
> >
> > > PeterZ has suggested some optimization which I sent out yesterday, I
> > > suppose they haven't been incl
On Sun, Jul 07, 2013 at 08:43:25AM +0200, Mike Galbraith wrote:
> On Fri, 2013-07-05 at 14:16 +0800, Michael Wang wrote:
>
> > PeterZ has suggested some optimization which I sent out yesterday, I
> > suppose they haven't been included into this test yet, correct?
>
> No, that was with both v3 pat
On Mon, 2013-07-08 at 10:49 +0800, Michael Wang wrote:
> BTW, could you please show me the '/proc/cpuinfo' of your box? I'd like
> to collect some data for analyse later ;-)
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Core
On 07/07/2013 02:43 PM, Mike Galbraith wrote:
> On Fri, 2013-07-05 at 14:16 +0800, Michael Wang wrote:
>
>> PeterZ has suggested some optimization which I sent out yesterday, I
>> suppose they haven't been included into this test yet, correct?
>
> No, that was with both v3 patches applied. hackb
On Fri, 2013-07-05 at 14:16 +0800, Michael Wang wrote:
> PeterZ has suggested some optimization which I sent out yesterday, I
> suppose they haven't been included into this test yet, correct?
No, that was with both v3 patches applied. hackbench -l 1000 delta
tracked to next pull/build fwiw, but
On 07/05/2013 01:41 PM, Mike Galbraith wrote:
[snip]
>>
>> Have you tried to use more loops and groups? will that show even bigger
>> regressions?
>
> Nope, less on either side.
>
> hackbench -g 100 -l 1000
>avg
> 3.10.0-regr
On Fri, 2013-07-05 at 12:33 +0800, Michael Wang wrote:
> On 07/05/2013 12:08 PM, Mike Galbraith wrote:
> [snip]
> >>
> >> Wow, I used to think such issue is very hard to be tracked by
> >> benchmarks, is this regression stable?
> >
> > Yeah, seems to be. I was curious as to why you saw an improve
On 07/05/2013 12:08 PM, Mike Galbraith wrote:
[snip]
>>
>> Wow, I used to think such issue is very hard to be tracked by
>> benchmarks, is this regression stable?
>
> Yeah, seems to be. I was curious as to why you saw an improvement to
> hackbench, didn't seem there should be any, so though I'd t
On Fri, 2013-07-05 at 10:47 +0800, Michael Wang wrote:
> On 07/04/2013 06:33 PM, Mike Galbraith wrote:
> [snip]
> >> Well, seems like we still have many follow-up research works after fix
> >> the issue ;-)
> >
> > Yeah. Like how to how to exterminate the plus sign, they munch cache
> > lines, a
On 07/04/2013 06:33 PM, Mike Galbraith wrote:
[snip]
>> Well, seems like we still have many follow-up research works after fix
>> the issue ;-)
>
> Yeah. Like how to how to exterminate the plus sign, they munch cache
> lines, and have a general tendency to negatively impact benchmarks.
>
> Q6600
On Thu, 2013-07-04 at 17:38 +0800, Michael Wang wrote:
> On 07/04/2013 05:13 PM, Peter Zijlstra wrote:
> [snip]
> >
> > Right, but something like the below is limited in cost to at most 32/64 (I
> > forgot the type) shifts. Now its probably not worth doing, but it shows
> > things like that can b
On 07/04/2013 05:13 PM, Peter Zijlstra wrote:
[snip]
>
> Right, but something like the below is limited in cost to at most 32/64 (I
> forgot the type) shifts. Now its probably not worth doing, but it shows
> things like that can be done in 'constant' time.
>
> now = jiffies;
> if (now - p->la
On Tue, Jul 02, 2013 at 05:35:33PM +0800, Michael Wang wrote:
> >> + if (jiffies > current->last_switch_decay + HZ) {
> >> + current->nr_wakee_switch = 0;
> >> + current->last_switch_decay = jiffies;
> >> + }
> >
> > This isn't so much a decay as it is wiping state. Did you try
On 07/02/2013 05:35 PM, Michael Wang wrote:
[snip]
>> I've seen there's some discussion as to this function name.. good :-) It
>> really wants to change. How about something like:
>>
>> int wake_affine()
>> {
>> ...
>>
>> /*
>>* If we wake multiple tasks be careful to not bounce
>>* our
Hi, Peter
Thanks for your review :)
On 07/02/2013 04:52 PM, Peter Zijlstra wrote:
[snip]
>> +static void record_wakee(struct task_struct *p)
>> +{
>> +/*
>> + * Rough decay, don't worry about the boundary, really active
>> + * task won't care the loose.
>> + */
>
> OK so we 'deca
On Tue, Jul 02, 2013 at 12:43:44PM +0800, Michael Wang wrote:
> Signed-off-by: Michael Wang
> ---
> include/linux/sched.h |3 +++
> kernel/sched/fair.c | 45 +
> 2 files changed, 48 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/
On 07/02/2013 02:29 PM, Mike Galbraith wrote:
> On Tue, 2013-07-02 at 14:17 +0800, Michael Wang wrote:
>
>> As Peter mentioned before, we currently need some solution like the
>> buddy-idea, and when folks report regression (I suppose they won't...),
>> we will have more data then.
>>
>> So we cou
On Tue, 2013-07-02 at 14:17 +0800, Michael Wang wrote:
> As Peter mentioned before, we currently need some solution like the
> buddy-idea, and when folks report regression (I suppose they won't...),
> we will have more data then.
>
> So we could firstly try to regain the lost performance of pgben
On 07/02/2013 01:54 PM, Mike Galbraith wrote:
> On Tue, 2013-07-02 at 12:43 +0800, Michael Wang wrote:
>> Since RFC:
>> Tested again with the latest tip 3.10.0-rc7.
>>
>> wake-affine stuff is always trying to pull wakee close to waker, by theory,
>> this will bring benefit if waker's cpu cach
On Tue, 2013-07-02 at 12:43 +0800, Michael Wang wrote:
> Since RFC:
> Tested again with the latest tip 3.10.0-rc7.
>
> wake-affine stuff is always trying to pull wakee close to waker, by theory,
> this will bring benefit if waker's cpu cached hot data for wakee, or the
> extreme ping-pong c
On 07/02/2013 01:38 PM, Mike Galbraith wrote:
> On Tue, 2013-07-02 at 12:43 +0800, Michael Wang wrote:
>
>> +static int nasty_pull(struct task_struct *p)
>> +{
>> +int factor = cpumask_weight(cpu_online_mask);
>> +
>> +/*
>> + * Yeah, it's the switching-frequency, could means many wake
On Tue, 2013-07-02 at 12:43 +0800, Michael Wang wrote:
> +static int nasty_pull(struct task_struct *p)
> +{
> + int factor = cpumask_weight(cpu_online_mask);
> +
> + /*
> + * Yeah, it's the switching-frequency, could means many wakee or
> + * rapidly switch, use factor here will
Since RFC:
Tested again with the latest tip 3.10.0-rc7.
wake-affine stuff is always trying to pull wakee close to waker, by theory,
this will bring benefit if waker's cpu cached hot data for wakee, or the
extreme ping-pong case.
And testing show it could benefit hackbench 15% at most.
Ho
Hi, Peter
Would you like to give some comments on this approach? or may be just
some hint on what's the concern? the damage on pgbench is still there...
Regards,
Michael Wang
On 05/28/2013 01:05 PM, Michael Wang wrote:
> wake-affine stuff is always trying to pull wakee close to waker, by theory
On 06/03/2013 02:05 PM, Mike Galbraith wrote:
> On Mon, 2013-06-03 at 13:50 +0800, Michael Wang wrote:
>> On 06/03/2013 01:22 PM, Mike Galbraith wrote:
>> [snip]
I agree that this idea, in other work, 'stop wake-affine when current is
busy with wakeup' may miss the chance to bring b
On Mon, 2013-06-03 at 13:50 +0800, Michael Wang wrote:
> On 06/03/2013 01:22 PM, Mike Galbraith wrote:
> [snip]
> >>
> >> I agree that this idea, in other work, 'stop wake-affine when current is
> >> busy with wakeup' may miss the chance to bring benefit, although I could
> >> not find such worklo
On 06/03/2013 01:22 PM, Mike Galbraith wrote:
[snip]
>>
>> I agree that this idea, in other work, 'stop wake-affine when current is
>> busy with wakeup' may miss the chance to bring benefit, although I could
>> not find such workload, but I can't do promise...
>
> Someday we'll find the perfect ba
On Mon, 2013-06-03 at 12:52 +0800, Michael Wang wrote:
> On 06/03/2013 11:53 AM, Mike Galbraith wrote:
> > On Mon, 2013-06-03 at 11:26 +0800, Michael Wang wrote:
> >> On 06/03/2013 11:09 AM, Mike Galbraith wrote:
> >>> On Mon, 2013-06-03 at 10:28 +0800, Michael Wang wrote:
> On 05/28/2013 0
On 06/03/2013 11:53 AM, Mike Galbraith wrote:
> On Mon, 2013-06-03 at 11:26 +0800, Michael Wang wrote:
>> On 06/03/2013 11:09 AM, Mike Galbraith wrote:
>>> On Mon, 2013-06-03 at 10:28 +0800, Michael Wang wrote:
On 05/28/2013 01:05 PM, Michael Wang wrote:
> wake-affine stuff is always try
On Mon, 2013-06-03 at 11:26 +0800, Michael Wang wrote:
> On 06/03/2013 11:09 AM, Mike Galbraith wrote:
> > On Mon, 2013-06-03 at 10:28 +0800, Michael Wang wrote:
> >> On 05/28/2013 01:05 PM, Michael Wang wrote:
> >>> wake-affine stuff is always trying to pull wakee close to waker, by
> >>> theor
On 06/03/2013 11:09 AM, Mike Galbraith wrote:
> On Mon, 2013-06-03 at 10:28 +0800, Michael Wang wrote:
>> On 05/28/2013 01:05 PM, Michael Wang wrote:
>>> wake-affine stuff is always trying to pull wakee close to waker, by theory,
>>> this will bring benefit if waker's cpu cached hot data for wakee
On Mon, 2013-06-03 at 10:28 +0800, Michael Wang wrote:
> On 05/28/2013 01:05 PM, Michael Wang wrote:
> > wake-affine stuff is always trying to pull wakee close to waker, by theory,
> > this will bring benefit if waker's cpu cached hot data for wakee, or the
> > extreme ping-pong case.
> >
> > And
On 05/28/2013 01:05 PM, Michael Wang wrote:
> wake-affine stuff is always trying to pull wakee close to waker, by theory,
> this will bring benefit if waker's cpu cached hot data for wakee, or the
> extreme ping-pong case.
>
> And testing show it could benefit hackbench 15% at most.
>
> However,
wake-affine stuff is always trying to pull wakee close to waker, by theory,
this will bring benefit if waker's cpu cached hot data for wakee, or the
extreme ping-pong case.
And testing show it could benefit hackbench 15% at most.
However, the whole stuff is somewhat blindly and time-consuming, so
43 matches
Mail list logo
