On 2019/7/12 下午4:58, 王贇 wrote:
[snip]
>
> I see, we should not override the decision of select_idle_sibling().
>
> Actually the original design we try to achieve is:
>
> let wake affine select the target
> try find idle sibling of target
> if got one
> pick it
> else if task cli
On 2019/7/12 下午3:53, Peter Zijlstra wrote:
[snip]
return target;
}
>>>
>>> Select idle sibling should never cross node boundaries and is thus the
>>> entirely wrong place to fix anything.
>>
>> Hmm.. in our early testing the printk show both select_task_rq_fair() and
>> task_numa_f
On Fri, Jul 12, 2019 at 11:10:08AM +0800, 王贇 wrote:
> On 2019/7/11 下午10:27, Peter Zijlstra wrote:
> >> Thus we introduce the numa cling, which try to prevent tasks leaving
> >> the preferred node on wakeup fast path.
> >
> >
> >> @@ -6195,6 +6447,13 @@ static int select_idle_sibling(struct task_
On 2019/7/11 下午10:27, Peter Zijlstra wrote:
[snip]
>> Thus we introduce the numa cling, which try to prevent tasks leaving
>> the preferred node on wakeup fast path.
>
>
>> @@ -6195,6 +6447,13 @@ static int select_idle_sibling(struct task_struct *p,
>> int prev, int target)
>> if ((unsig
On Wed, Jul 03, 2019 at 11:34:16AM +0800, 王贇 wrote:
> Although we paid so many effort to settle down task on a particular
> node, there are still chances for a task to leave it's preferred
> node, that is by wakeup, numa swap migrations or load balance.
>
> When we are using cpu cgroup in share wa
5 matches
Mail list logo
