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
15 matches
Mail list logo
