linux-kernel - Re: [PATCH 32/40] async: introduce workqueue based alternative implementation

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:	Wed, 20 Jan 2010 09:19:47 +0900
From:	Tejun Heo <tj@...nel.org>
To:	Arjan van de Ven <arjan@...ux.intel.com>
CC:	torvalds@...ux-foundation.org, mingo@...e.hu, peterz@...radead.org,
	awalls@...ix.net, linux-kernel@...r.kernel.org, jeff@...zik.org,
	akpm@...ux-foundation.org, jens.axboe@...cle.com,
	rusty@...tcorp.com.au, cl@...ux-foundation.org,
	dhowells@...hat.com, avi@...hat.com, johannes@...solutions.net,
	andi@...stfloor.org, Arjan van de Ven <arjan@...radead.org>
Subject: Re: [PATCH 32/40] async: introduce workqueue based alternative implementation

Hello, Arjan.

On 01/19/2010 11:37 PM, Arjan van de Ven wrote:
>> This too can be implemented using wq directly.  More below.
> 
> however you are forcing the function to be split in pieces,
> which makes for a more complex programming model.
> For example, I have trouble proving to myself that your ata conversion
> is acutally correct.

I think it is.  :-)

>> The tradeoff changes with the worker pool implementation can be shared
>> with workqueue which provides its own ways to control concurrency and
>> synchronize. 
> 
> while I don't mind sharing the pool implementation (all 20 lines of
> it ;-), I don't think the objective of sharing some implementation
> detail is worth complicating the programming model.

Oh yeah, we can definitely pay some lines of code for a separate
synchronization model if it makes driver writers' lives easier.  I'm
just wondering whether the benefit is enough to justify a separate
sync model.

>> Before, the cookie based synchronization is something
>> inherent to the async mechanism.  The async worker pool was needed and
>> the synchronization mechanism came integrated with it.  Now that the
>> backend can be replaced with workqueue which supplies its own ways of
>> synchronization, the cookie based synchronization model needs stronger
>> justification as it no longer comes as a integral part of something
>> bigger which is needed anyway.
> 
> the wq model is either "full async" or "fully ordered".
> the cookie mechanism allows for "run async for the expensive bit, and
> then INSIDE THE SAME FUNCTION, synchronize, and then run some more".

Hmmm...

>> If so, we can leave the list based cookie synchronization alone and
>> simply use wq's to provide concurrency only without using its
>> synchronization mechanisms (flushes).
> 
> can you flush from inside a wq element?  That's the critical part
> that makes the cookie based system easy to program.

Yeah, you can flush individual works from other works and wqs from
works running from different wqs.  What's not allowed is flushing the
wq a work is running on from the work.  Let's say if the flush code
can be modified to do so, would that change your opinion?

Thanks.

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