Message-ID: <4C18E4B7.5040702@kernel.org>
Date:	Wed, 16 Jun 2010 16:50:31 +0200
From:	Tejun Heo <tj@...nel.org>
To:	Daniel Walker <dwalker@...eaurora.org>
CC:	mingo@...e.hu, awalls@...ix.net, linux-kernel@...r.kernel.org,
	jeff@...zik.org, akpm@...ux-foundation.org, rusty@...tcorp.com.au,
	cl@...ux-foundation.org, dhowells@...hat.com,
	arjan@...ux.intel.com, johannes@...solutions.net, oleg@...hat.com,
	axboe@...nel.dk
Subject: Re: Overview of concurrency managed workqueue

Hi,

On 06/16/2010 04:34 PM, Daniel Walker wrote:
>> 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.
> 
> You just don't understand the use case. Let say I have a high priority
> thread in userspace , and I discover through analysis that my thread is
> being forced to wait on a workqueue thread (priority inversion) , so
> then I just increase the workqueue thread priority to overcome the
> inversion. That's totally valid, and you don't even need to know exactly
> what the thread is doing..
> 
> Now lets say the same thing happens under your changes.. Well, then I'm
> screwed cause your changes turn the workqueues into a opaque thread
> cloud which can't be prioritized.

If you find that some work item is causing priority inversion, you
need to fix the problem instead of working around in adhoc way which
won't be useful to anyone else, so, no, it doesn't sound like a useful
use case.

>>> 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.
> 
> Exactly, but I do know about it which is why we're talking. So your
> saying that use cases that you don't know about don't really matter
> right?

Peter brought up the work priority issue previously and Linus was
pretty clear on the issue.  They're in the discussiosn for the first
or second take.

> Your completely wrong .. Look at the example I gave above .. Bottom line
> is that your removing currently useful functionality, which is bad.. You
> can say it's not useful, but again you also say you don't "have much
> idea" regarding the cases where this is actually important.

I said that I didn't have much idea about RT work priority thing, not
setting priority on wq workers for adhoc workaround for whatever.
IIRC, the RT work priority thing Peter was talking about was a
different thing.  Sure, more complex workqueue implementation would
complicate implementing work priorities, but if necessary maybe we can
grow different classes of worker pools.

> Could you please just entertain the idea that maybe someone somewhere
> might want to give priorities to the work items inside your system.

If that's necessary, do it properly.  Give *work* priorities or at
least give explicit priorities to workqueues.  That's a completely
different thing from insisting fixed workqueue to kthread mapping so
that three people on the whole planet can set priority on those
kthreads not even knowing what the hell they do.

> I mean consider the RT workqueue that you removed, why in the world
> would we even have that if giving workqueues special priorities was
> a bad thing (or not useful).

Because stop_machine wnated to use wq as a frontend for threads which
I converted to cpu_stop and which actually proves my point not yours,
sorry.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists