[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:
>
>
[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:
if (now
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
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 2 task
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.
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. Imagine
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
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
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
On 03/11/2013 05:40 PM, Ingo Molnar wrote:
* Michael Wang wang...@linux.vnet.ibm.com 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
* Michael Wang wang...@linux.vnet.ibm.com wrote:
On 03/11/2013 05:40 PM, Ingo Molnar wrote:
* Michael Wang wang...@linux.vnet.ibm.com wrote:
Hi, Ingo
On 03/11/2013 04:21 PM, Ingo Molnar wrote:
[snip]
I have actually written the prctl() approach before, for instrumentation
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 make them
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 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
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
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
* 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
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
* Peter Zijlstra a.p.zijls...@chello.nl 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
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 :)
* Michael Wang wang...@linux.vnet.ibm.com 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
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...could
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 where this
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 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.
Isn't the
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 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 by
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:
>
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,
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 &&
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
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
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
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
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
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
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
work well
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 his buddy.
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 sched pipe'
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
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, but it
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() stuff is trying
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
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-pipe is a
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 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 bench sched
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 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))
+ /*
+
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'
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'
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
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
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
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
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?
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
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
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
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 task on rq
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
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 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 fix it,
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? The comments
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.
Bad to know
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 lot
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
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 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 _were_ a promise,
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 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 get
a
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
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
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
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
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 run
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 sleep,
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 it is
+
88 matches
Mail list logo
