lkml.org 
[lkml]   [2007]   [Aug]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] RT: Add priority-queuing and priority-inheritance to workqueue infrastructure
From
Date
On Mon, 2007-08-06 at 18:45 +0400, Oleg Nesterov wrote:
> On 08/06, Peter Zijlstra wrote:

> > still this does not change the fundamental issue of a high prio piece of
> > work waiting on a lower prio task.
> ^^^^^^^
> waiting. This is a "key" word, and this was my (perhaps wrong) point.

Yeah, its having a higher prio item processed at a lower prio that is
the problem. It might be delayed by less important issues.

But I'm feeling a question wanting to jump out of your statement, I just
fail to find it.

> > > I suspect most of the barrier/flush semantics could be replaced with
> > > completions from specific work items.
>
> Hm. But this is exactly how it works?

Ah, I fail to be clear :-/

Yes, barriers work by enqueueing work and waiting for that one work item
to fall out, thereby knowing that all previous work has been completed.

My point was that most flushes are there to wait for a previously
enqueued work item, and might as well wait for that one.

Let me try to illustrate: a regular pattern is, we enqueue work A and
then flush the whole queue to ensure A is processed. So instead of
enqueueing A, then B in the barrier code, and wait for B to pop out, we
might as well wait for A to begin with.



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

\
 
 \ /
  Last update: 2007-08-06 16:55    [W:0.046 / U:0.336 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site