Re: [RFC 09/16] kgr: mark task_safe in some kthreads

[Tejun Heo <tj@kernel.org>]

Hey, Mike.

On Thu, May 15, 2014 at 05:53:57AM +0200, Mike Galbraith wrote:
> Hm.  The user would need to be able to identify and prioritize the

I suppose you mean userland by "the user"?

> things, and have his settings stick.  Any dynamic pool business doing
> allocations and/or munging priorities would be highly annoying.

There are some use cases where control over worker priority or other
attributes are necessary.  I'm not sure using kthread for that reason
is a good engineering choice tho.  Many of those cases end up being
accidental.

I think it'd be healthier to identify the use cases and then provide
proper interface for it.  Note that workqueue can now expose interface
to modify concurrency, priority and cpumask to userland which
writeback workers are already using.

In general, being restricted to using kthread internally for this
reason seems wrong to me.  It's too direct influence on the
implementation mechanism.

> I saw a case where dynamic workers inflicted a realtime regression on a
> user (but what they were getting away with previously was.. horrid).

Yeah, exactly.  It'd be far better to identify the use case properly
and provide the appropriate interface for it.  That said, even if it
really requires diddling with kthread directly from userland,
kthread_worker can still be used.  It's still one dedicated kthread
but with structured usage from kernel side so that infrastructure
features like freezer and possibly kgr can be implemented in a single
place rather than scattered around all over the place.

Thanks.

-- 
tejun