Messages in this thread | | | Date | Thu, 15 May 2014 00:06:08 -0400 | From | Tejun Heo <> | Subject | Re: [RFC 09/16] kgr: mark task_safe in some kthreads |
| |
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
| |