On Wed, 2010-06-16 at 21:20 +0200, Tejun Heo wrote:
quoted text
> On 06/16/2010 08:46 PM, Tejun Heo wrote:
> > * I'm very sorry I'm breaking your hacky workaround but seriously
> >   that's another problem to solve.  Let's talk about the problem
> >   itself instead of your hacky workaround.  (I think for most cases
> >   not using workqueue in RT path would be the right thing to do.)
> 
> For example, for the actual case of amba-pl022.c you mentioned, where
> interrupt handler sometimes offloads to workqueue, convert
> amba-pl022.c to use threaded interrupt handler.  That's why it's
> there.
> 
> If you actually _solve_ the problem like this, other users wouldn't
> experience the problem at all once the update reaches them and you
> won't have to worry about your workaround breaking with the next
> kernel update or unexpected suspend/resume and we won't be having this
> discussion about adjusting workqueue priorities from userland.

What you suggesting just means the user has to adjust an interrupt
thread instead of a workqueue thread. That really doesn't change
anything, since it's just another type of kernel thread.

quoted text
> There are many wrong things about working around RT latency problems
> by setting workqueue priorities from userland.  Please think about why
> the driver would have a separate workqueue for itself in the first
> place.  It was to work around the limitation of workqueue facility and
> you're arguing that, because that work around allows yet another very
> fragile workaround, the property which made the original work around
> necessary in the first place needs to stay.  That sounds really
> perverse to me.

I have no idea what your trying to say here.. I'm sure there is no one
reason why people use workqueues in their drivers. In fact I'm sure
there are many reasons to use workqueues or not to use them.

Daniel

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