[snip]
>> It could bring the same benefit but at lower overhead, what's the point
>> of computing the same value over and over again? Also, the rate limit
>> thing naturally works for the soft/hard-irq case.
>
> Just try to confirm my understanding, so we are going to do something
> like:
>
>
On 03/14/2013 06:58 PM, Peter Zijlstra wrote:
> On Wed, 2013-03-13 at 11:07 +0800, Michael Wang wrote:
>
>> However, we already figure out the logical that wakeup related task
>> could benefit from closely running, this could promise us somewhat
>> reliable benefit.
>
> I'm not convinced that the
On Wed, 2013-03-13 at 11:07 +0800, Michael Wang wrote:
> However, we already figure out the logical that wakeup related task
> could benefit from closely running, this could promise us somewhat
> reliable benefit.
I'm not convinced that the 2 task wakeup scenario is the only sane
scenario. Imagin
On 03/12/2013 06:08 PM, Peter Zijlstra wrote:
> Does something simple like a per-task throttle of wake_affine() gain
> similar benefits? Say something like only do wake_affine() once every
> 10 ms or so (counting on the wakee, not waker).
>
> The rationale being that wake_affine() relies on load-b
Does something simple like a per-task throttle of wake_affine() gain
similar benefits? Say something like only do wake_affine() once every
10 ms or so (counting on the wakee, not waker).
The rationale being that wake_affine() relies on load-balance
statistics that aren't updated that much faster,
On 03/12/2013 04:48 PM, Ingo Molnar wrote:
[snip]
>>>
>>> Instrumentation/stats/profiling will also double check the correctness of
>>> this data: if developers/users start relying on the work metric as a
>>> substitute benchmark number, then app writers will have an additional
>>> incentive to
* Michael Wang wrote:
> On 03/11/2013 05:40 PM, Ingo Molnar wrote:
> >
> > * Michael Wang wrote:
> >
> >> Hi, Ingo
> >>
> >> On 03/11/2013 04:21 PM, Ingo Molnar wrote:
> >> [snip]
> >>>
> >>> I have actually written the prctl() approach before, for instrumentation
> >>> purposes, and it does
On 03/11/2013 05:40 PM, Ingo Molnar wrote:
>
> * Michael Wang wrote:
>
>> Hi, Ingo
>>
>> On 03/11/2013 04:21 PM, Ingo Molnar wrote:
>> [snip]
>>>
>>> I have actually written the prctl() approach before, for instrumentation
>>> purposes, and it does wonders to system analysis.
>>
>> The idea sou
On 03/11/2013 06:36 PM, Peter Zijlstra wrote:
> On Fri, 2013-03-08 at 10:50 +0800, Michael Wang wrote:
>
>>> OK, so there's two issues I have with all this are:
>>>
>>> - it completely wrecks task placement for things like interrupts (sadly I
>>> don't
>>> have a good idea about a benchmark
On Fri, 2013-03-08 at 10:50 +0800, Michael Wang wrote:
> > OK, so there's two issues I have with all this are:
> >
> > - it completely wrecks task placement for things like interrupts (sadly I
> > don't
> > have a good idea about a benchmark where this matters).
>
> I don't get this point
* Michael Wang wrote:
> Hi, Ingo
>
> On 03/11/2013 04:21 PM, Ingo Molnar wrote:
> [snip]
> >
> > I have actually written the prctl() approach before, for instrumentation
> > purposes, and it does wonders to system analysis.
>
> The idea sounds great, we could get many new info to implement m
Hi, Ingo
On 03/11/2013 04:21 PM, Ingo Molnar wrote:
[snip]
>
> I have actually written the prctl() approach before, for instrumentation
> purposes, and it does wonders to system analysis.
The idea sounds great, we could get many new info to implement more
smart scheduler, that's amazing :)
>
* Peter Zijlstra wrote:
> On Wed, 2013-03-06 at 15:06 +0800, Michael Wang wrote:
>
> > wake_affine() stuff is trying to bind related tasks closely, but it
> > doesn't work well according to the test on 'perf bench sched pipe'
> > (thanks to Peter).
>
> so sched-pipe is a poor benchmark for t
On 03/08/2013 04:26 PM, Mike Galbraith wrote:
> On Fri, 2013-03-08 at 15:30 +0800, Michael Wang wrote:
>> On 03/08/2013 02:44 PM, Mike Galbraith wrote:
>
>>> In general, I think things would work better if we'd just rate limit how
>>> frequently we can wakeup migrate each individual task.
>>
>>
On Fri, 2013-03-08 at 15:30 +0800, Michael Wang wrote:
> On 03/08/2013 02:44 PM, Mike Galbraith wrote:
> > In general, I think things would work better if we'd just rate limit how
> > frequently we can wakeup migrate each individual task.
>
> Isn't the wakeup buddy already limit the rate? and
On 03/08/2013 02:44 PM, Mike Galbraith wrote:
> On Fri, 2013-03-08 at 10:37 +0800, Michael Wang wrote:
>> On 03/07/2013 05:43 PM, Mike Galbraith wrote:
>>> On Thu, 2013-03-07 at 09:36 +0100, Peter Zijlstra wrote:
On Wed, 2013-03-06 at 15:06 +0800, Michael Wang wrote:
> wake_affine()
On Fri, 2013-03-08 at 10:37 +0800, Michael Wang wrote:
> On 03/07/2013 05:43 PM, Mike Galbraith wrote:
> > On Thu, 2013-03-07 at 09:36 +0100, Peter Zijlstra wrote:
> >> On Wed, 2013-03-06 at 15:06 +0800, Michael Wang wrote:
> >>
> >>> wake_affine() stuff is trying to bind related tasks closely, b
On 03/08/2013 01:27 AM, Peter Zijlstra wrote:
> On Wed, 2013-03-06 at 15:06 +0800, Michael Wang wrote:
>> @@ -3351,7 +3420,13 @@ select_task_rq_fair(struct task_struct *p, int
>> sd_flag, int wake_flags)
>> }
>>
>> if (affine_sd) {
>> - if (cpu != prev_cpu && wake_af
On 03/07/2013 05:43 PM, Mike Galbraith wrote:
> On Thu, 2013-03-07 at 09:36 +0100, Peter Zijlstra wrote:
>> On Wed, 2013-03-06 at 15:06 +0800, Michael Wang wrote:
>>
>>> wake_affine() stuff is trying to bind related tasks closely, but it doesn't
>>> work well according to the test on 'perf bench s
On 03/08/2013 01:21 AM, Peter Zijlstra wrote:
> On Wed, 2013-03-06 at 15:06 +0800, Michael Wang wrote:
>> +static inline int wakeup_related(struct task_struct *p)
>> +{
>> + if (wakeup_buddy(p, current)) {
>> + /*
>> +* Now check whether current still focus on hi
On 03/08/2013 12:52 AM, Peter Zijlstra wrote:
> On Thu, 2013-03-07 at 17:46 +0800, Michael Wang wrote:
>
>> On 03/07/2013 04:36 PM, Peter Zijlstra wrote:
>>> On Wed, 2013-03-06 at 15:06 +0800, Michael Wang wrote:
>>>
wake_affine() stuff is trying to bind related tasks closely, but it doesn't
On Wed, 2013-03-06 at 15:06 +0800, Michael Wang wrote:
> @@ -3351,7 +3420,13 @@ select_task_rq_fair(struct task_struct *p, int
> sd_flag, int wake_flags)
> }
>
> if (affine_sd) {
> - if (cpu != prev_cpu && wake_affine(affine_sd, p,
> sync))
> + /*
> +
On Wed, 2013-03-06 at 15:06 +0800, Michael Wang wrote:
> +static inline int wakeup_related(struct task_struct *p)
> +{
> + if (wakeup_buddy(p, current)) {
> + /*
> +* Now check whether current still focus on his buddy.
> +*/
> + if (
On Thu, 2013-03-07 at 17:46 +0800, Michael Wang wrote:
> On 03/07/2013 04:36 PM, Peter Zijlstra wrote:
> > On Wed, 2013-03-06 at 15:06 +0800, Michael Wang wrote:
> >
> >> wake_affine() stuff is trying to bind related tasks closely, but it doesn't
> >> work well according to the test on 'perf benc
Hi, Peter
Thanks for your reply.
On 03/07/2013 04:36 PM, Peter Zijlstra wrote:
> On Wed, 2013-03-06 at 15:06 +0800, Michael Wang wrote:
>
>> wake_affine() stuff is trying to bind related tasks closely, but it doesn't
>> work well according to the test on 'perf bench sched pipe' (thanks to Peter
On Thu, 2013-03-07 at 09:36 +0100, Peter Zijlstra wrote:
> On Wed, 2013-03-06 at 15:06 +0800, Michael Wang wrote:
>
> > wake_affine() stuff is trying to bind related tasks closely, but it doesn't
> > work well according to the test on 'perf bench sched pipe' (thanks to
> > Peter).
>
> so sched-
On Wed, 2013-03-06 at 15:06 +0800, Michael Wang wrote:
> wake_affine() stuff is trying to bind related tasks closely, but it doesn't
> work well according to the test on 'perf bench sched pipe' (thanks to Peter).
so sched-pipe is a poor benchmark for this..
Ideally we'd write a new benchmark th
Log since RFC:
1. Small fix (thanks to Namhyung).
2. Remove the logical branch which will bind two task on
same cpu (thanks to Mike).
wake_affine() stuff is trying to bind related tasks closely, but it doesn't
work well according to the test on 'perf bench sched pipe' (t
On 02/28/2013 11:31 PM, Namhyung Kim wrote:
> 2013-02-28 (목), 11:06 +0100, Mike Galbraith:
>> On Thu, 2013-02-28 at 18:25 +0900, Namhyung Kim wrote:
>>
>>> Not sure if it should require bidirectional relationship. Looks like
>>> just for benchmarks. Isn't there a one-way relationship that could g
Hi, Namhyung
Thanks for your reply.
On 02/28/2013 05:25 PM, Namhyung Kim wrote:
[snip]
>> Thus, if B is also the wakeup buddy of A, which means no other task has
>> destroyed their relationship, then A is likely to benefit from the cached
>> data of B, make them running closely is likely to gain
On 02/28/2013 05:18 PM, Mike Galbraith wrote:
> On Thu, 2013-02-28 at 16:49 +0800, Michael Wang wrote:
>> On 02/28/2013 04:24 PM, Mike Galbraith wrote:
>>> On Thu, 2013-02-28 at 16:14 +0800, Michael Wang wrote:
On 02/28/2013 04:04 PM, Mike Galbraith wrote:
>>>
> It would be nice if it _w
2013-02-28 (목), 11:06 +0100, Mike Galbraith:
> On Thu, 2013-02-28 at 18:25 +0900, Namhyung Kim wrote:
>
> > Not sure if it should require bidirectional relationship. Looks like
> > just for benchmarks. Isn't there a one-way relationship that could get
> > a benefit from this? I don't know ;-)
>
On Thu, 2013-02-28 at 18:25 +0900, Namhyung Kim wrote:
> Not sure if it should require bidirectional relationship. Looks like
> just for benchmarks. Isn't there a one-way relationship that could get
> a benefit from this? I don't know ;-)
?? Meaningful relationships are bare minimum bidirecti
Hi Michael,
On Thu, 28 Feb 2013 14:38:03 +0800, Michael Wang wrote:
> wake_affine() stuff is trying to bind related tasks closely, but it doesn't
> work well according to the test on 'perf bench sched pipe' (thanks to Peter).
>
> Besides, pgbench show that blindly using wake_affine() will eat a lo
On Thu, 2013-02-28 at 16:49 +0800, Michael Wang wrote:
> On 02/28/2013 04:24 PM, Mike Galbraith wrote:
> > On Thu, 2013-02-28 at 16:14 +0800, Michael Wang wrote:
> >> On 02/28/2013 04:04 PM, Mike Galbraith wrote:
> >
> >>> It would be nice if it _were_ a promise, but it is not, it's a hint.
> >>
On 02/28/2013 04:24 PM, Mike Galbraith wrote:
> On Thu, 2013-02-28 at 16:14 +0800, Michael Wang wrote:
>> On 02/28/2013 04:04 PM, Mike Galbraith wrote:
>
>>> It would be nice if it _were_ a promise, but it is not, it's a hint.
>>
>> Bad to know :(
>>
>> Should we fix it or this is by designed? Th
On Thu, 2013-02-28 at 16:14 +0800, Michael Wang wrote:
> On 02/28/2013 04:04 PM, Mike Galbraith wrote:
> > It would be nice if it _were_ a promise, but it is not, it's a hint.
>
> Bad to know :(
>
> Should we fix it or this is by designed? The comments after WF_SYNC
> cheated me...
You can't f
On 02/28/2013 04:04 PM, Mike Galbraith wrote:
> On Thu, 2013-02-28 at 15:40 +0800, Michael Wang wrote:
>> Hi, Mike
>>
>> Thanks for your reply.
>>
>> On 02/28/2013 03:18 PM, Mike Galbraith wrote:
>>> On Thu, 2013-02-28 at 14:38 +0800, Michael Wang wrote:
>>>
+ /*
On Thu, 2013-02-28 at 15:42 +0800, Michael Wang wrote:
> I mean could we say that more ops/sec means more works has been done?
Sure. But it's fairly meaningless, it's all scheduler. Real tasks do
more than schedule.
-Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kern
On Thu, 2013-02-28 at 15:40 +0800, Michael Wang wrote:
> Hi, Mike
>
> Thanks for your reply.
>
> On 02/28/2013 03:18 PM, Mike Galbraith wrote:
> > On Thu, 2013-02-28 at 14:38 +0800, Michael Wang wrote:
> >
> >> + /*
> >> + * current is the only
On 02/28/2013 03:40 PM, Michael Wang wrote:
> Hi, Mike
>
> Thanks for your reply.
>
> On 02/28/2013 03:18 PM, Mike Galbraith wrote:
>> On Thu, 2013-02-28 at 14:38 +0800, Michael Wang wrote:
>>
>>> + /*
>>> +* current is the only task on rq and
Hi, Mike
Thanks for your reply.
On 02/28/2013 03:18 PM, Mike Galbraith wrote:
> On Thu, 2013-02-28 at 14:38 +0800, Michael Wang wrote:
>
>> +/*
>> + * current is the only task on rq and it is
>> + * going to slee
On Thu, 2013-02-28 at 14:38 +0800, Michael Wang wrote:
> + /*
> + * current is the only task on rq and it is
> + * going to sleep, current cpu will be a nice
> + * candidate for p to
wake_affine() stuff is trying to bind related tasks closely, but it doesn't
work well according to the test on 'perf bench sched pipe' (thanks to Peter).
Besides, pgbench show that blindly using wake_affine() will eat a lot of
performance.
Thus, we need a new solution, it should detect the tasks
44 matches
Mail list logo