Re: [PATCH 3/3] workqueue: Schedule work on non-idle cpu instead ofcurrent one
From: Vincent Guittot
Date: Tue Sep 25 2012 - 07:38:40 EST
On 25 September 2012 13:30, Viresh Kumar <viresh.kumar@xxxxxxxxxx> wrote:
> On 25 September 2012 16:52, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
>> On Tue, 2012-09-25 at 16:06 +0530, Viresh Kumar wrote:
>>> @@ -1066,8 +1076,9 @@ int queue_work(struct workqueue_struct *wq,
>>> struct work_struct *work)
>>> {
>>> int ret;
>>>
>>> - ret = queue_work_on(get_cpu(), wq, work);
>>> - put_cpu();
>>> + preempt_disable();
>>> + ret = queue_work_on(wq_select_cpu(), wq, work);
>>> + preempt_enable();
>>>
>>> return ret;
>>> }
>>
>> Right, so the problem I see here is that wq_select_cpu() is horridly
>> expensive..
>
> But this is what the initial idea during LPC we had. Any improvements here
> you can suggest?
The main outcome of the LPC was that we should be able to select
another CPU than the local one.
Using the same policy than timer, is a 1st step to consolidate
interface. A next step should be to update the policy of the function
Vincent
>
>>> @@ -1102,7 +1113,7 @@ static void delayed_work_timer_fn(unsigned long
>>> __data)
>>> struct delayed_work *dwork = (struct delayed_work *)__data;
>>> struct cpu_workqueue_struct *cwq = get_work_cwq(&dwork->work);
>>>
>>> - __queue_work(smp_processor_id(), cwq->wq, &dwork->work);
>>> + __queue_work(wq_select_cpu(), cwq->wq, &dwork->work);
>>> }
>>
>> Shouldn't timer migration have sorted this one?
>
> Maybe yes. Will investigate more on it.
>
> Thanks for your early feedback.
>
> --
> viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/