Re: Overview of concurrency managed workqueue

[Tejun Heo]

Hello,

On 06/16/2010 04:05 PM, Daniel Walker wrote:
> On Wed, 2010-06-16 at 15:45 +0200, Tejun Heo wrote:
>> On 06/16/2010 03:41 PM, Daniel Walker wrote:
>>> Any workqueue that has a thread which can be prioritized from userspace.
>>> As long as there is a thread it can usually be given a priority from
>>> userspace, so any _current_ workqueue which uses a single thread or
>>> multiple threads is an example of what I'm talking about.
>>
>> Eh... what's the use case for that?  That's just so wrong.  What do
>> you do after a suspend/resume cycle?  Reprioritize all of them from
>> suspend/resume hooks?
> 
> The use case is any situation when the user wants to give higher
> priority to some set of work items, and there's nothing wrong with that.

Come on.  The user can't even know what's going on each workqueue
thread.  Something you can do doesn't make it a good idea.  In this
case, it's a very bad idea.

> In fact there has been a lot of work in the RT kernel related to
> workqueue prioritization ..

That frankly I don't have much idea about.

> suspend/resume shouldn't touch the thread priorities unless your tearing
> down the threads and remaking them each suspend/resume cycle from inside
> the kernel.

And here's a perfect example of why it's a very bad idea.  The kernel
is *ALREADY* doing that on every suspend/resume cycle, so if you are
thinking that priorities on kernel workqueue threads were being
maintained over suspend/resume cycles, you're wrong and have been
wrong for a very long time.

Mangling workqueue thread priorities from userland is a fundamentally
broken thing to do.  It's not a part of AP|BI and there's no guarantee
whatsoever that something which works currently in certain way will
keep working that way one release later.  If there's something which
wants priority adjustment from userland, the right thing to do is
finding out precisely why it's necesssary and implementing a published
interface to do that.

Thanks.

-- 
tejun
--
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/