Messages in this thread | | | Date | Thu, 17 Jun 2010 08:21:05 +0200 | From | Florian Mickler <> | Subject | Re: Overview of concurrency managed workqueue |
| |
On Thu, 17 Jun 2010 07:29:20 +0200 Florian Mickler <florian@mickler.org> wrote:
> On Wed, 16 Jun 2010 21:20:36 +0200 > Tejun Heo <tj@kernel.org> wrote: > > > 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. > > > > 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. > > > > For what its worth, IMO the right thing to do would probably be to > propagate the priority through the subsystem into the driver.
I was thinking about input devices here... anyway, my point is, that the user of the workqueue-interface should pass the priority-context to the workqueue subsystem...
If a userspace needs a driver to have a specific priority... can it inform the system about it (thinking sysfs here..)? that would prevent userspace having "to kick" the kernel if smth get's stuck....
Cheers, Flo
| |