linux-kernel - Re: [PATCH] RT: Add priority-queuing and priority-inheritance to workqueue infrastructure

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 06 Aug 2007 16:52:01 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Oleg Nesterov <oleg@...sign.ru>
Cc:	Ingo Molnar <mingo@...e.hu>, Gregory Haskins <ghaskins@...ell.com>,
	Daniel Walker <dwalker@...sta.com>,
	linux-rt-users@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] RT: Add priority-queuing and priority-inheritance to
	workqueue infrastructure

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/