On 08/01, Gregory Haskins wrote: > > On Thu, 2007-08-02 at 00:50 +0400, Oleg Nesterov wrote: > > On 08/01, Daniel Walker wrote: > > > > > > It's translating priorities through the work queues, which doesn't seem > > > to happen with the current implementation. A high priority, say > > > SCHED_FIFO priority 99, task may have to wait for a nice -5 work queue > > > to finish.. > > > > Why should that task wait? > > I assume "that task" = the RT99 task? If so, that is precisely the > question. It shouldn't wait. ;) With mainline, it is simply queued > with every other request. There could be an RT40, and a SCHED_NORMAL in > front of it in the queue that will get processed first. In addition, > the system could suffer from a priority inversion if some unrelated but > lower priority task (say RT98) was blocking the workqueue thread from > making forward progress on the nice -5 job. > > To clarify: when a design utilizes a singlethread per workqueue (such as > in both mainline and this patch), the RT99 will always have to wait > behind any already dispatched jobs. It is not that "RT99 will always have to wait". But yes, the work_struct queued by RT99 has to wait. > That is a given. However, with > Daniels patch, two things happen in addition to normal processing. Yes, I see what the patch does, > 1) The RT99 task would move ahead in the queue of anything else that was > also scheduled on the workqueue that is < RT99. this itself is wrong, breaks flush_workqueue() semantics > 2) The priority of the workqueue task would be temporarily elevated to > RT99 so that the currently dispatched task will complete at the same > priority as the waiter. _Which_ waiter? I can't understand at all why work_struct should "inherit" the priority of the task which queued it. This looks just wrong to me, even if could implement this safely. Oleg. - To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
