public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* Re: 答复: Re: [RFC PATCH V5 5/5] workqueue: introduce a way to setworkqueue's scheduler
       [not found] <201801291350022080675@zte.com.cn>
@ 2018-01-29  6:31 ` Mike Galbraith
  0 siblings, 0 replies; only message in thread
From: Mike Galbraith @ 2018-01-29  6:31 UTC (permalink / raw)
  To: wen.yang99
  Cc: tj, zhong.weidong, jiang.biao2, tan.hu, jiangshanlai, xiaolong.ye,
	linux-kernel

On Mon, 2018-01-29 at 13:50 +0800, wen.yang99@zte.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

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2018-01-29  6:32 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <201801291350022080675@zte.com.cn>
2018-01-29  6:31 ` 答复: Re: [RFC PATCH V5 5/5] workqueue: introduce a way to setworkqueue's scheduler Mike Galbraith

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox