[<prev] [next>] [day] [month] [year] [list]
Message-ID: <1517207502.7290.53.camel@gmx.de>
Date: Mon, 29 Jan 2018 07:31:42 +0100
From: Mike Galbraith <efault@....de>
To: wen.yang99@....com.cn
Cc: tj@...nel.org, zhong.weidong@....com.cn, jiang.biao2@....com.cn,
tan.hu@....com.cn, jiangshanlai@...il.com, xiaolong.ye@...el.com,
linux-kernel@...r.kernel.org
Subject: Re: 答复: Re: [RFC PATCH V5 5/5]
workqueue: introduce a way to setworkqueue's scheduler
On Mon, 2018-01-29 at 13:50 +0800, wen.yang99@....com.cn wrote:
>
> > What happens when a new kworker needs to be spawned?
> create_worker -> worker_attach_to_pool, in the function
> worker_attach_to_pool, we add this chunk:
>
> --- a/kernel/workqueue.c
> +++ b/kernel/workqueue.c
> @@ -1699,6 +1699,7 @@ static void worker_attach_to_pool(struct worker *worker,
> * online CPUs. It'll be re-applied when any of the CPUs come up.
> */
> set_cpus_allowed_ptr(worker->task, pool->attrs->cpumask);
> + sched_setattr(worker->task, &pool->attrs->sched_attr);
>
> /*
> * The pool->attach_mutex ensures %POOL_DISASSOCIATED remains
>
> pool->attach_mutex may guarante it, add sched_setattr may apply the
> wq's sched_attr to the spawned kworer.
That doesn't help kthreadd get to a CPU in a box being saturated by RT.
As long as you are careful, it's not a problem, I just mentioned it
because it's a hole.
-Mike
Powered by blists - more mailing lists