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

[Tejun Heo]

Hello, Arjan.

On 01/19/2010 09:57 AM, Arjan van de Ven wrote:
> there are two types:
> there's the domains, where you synchronize only within a domain,

Maps pretty nicely to a wq which is a queueing and flushing domain
after all.

> and then there's the "async string", think ACPI.  the ACPI init is a
> whole series of sort of dependent steps, where you synchronize about
> halfway, but the whole set runs async to all other inits in the
> system, and only near the very end when a full synchronization is
> done do you wait.  basically what you get (sorry, lame ascii graph)
> 
> ***************************************  (main init flow)
>    ***                driver 1
>    *  **            driver 2
>     *   **            driver 3
>     *     **            driver 4
>     *       **                  driver 5
> 
> where you get maximum concurrency during the pre-synchronization
> part, and a "chain" of synchronized execution *as part of the same
> function flow*, but possibly independent of other synchronization
> flows.

This too can be implemented using wq directly.  More below.

> the async infrastructure as you say took away the hassle of
> allocating, and more importantly, caring for the lifetime of the
> metadata object. But it also introduced a sychronization mechanism
> that is natural and simple for driver init and some other flows.

The tradeoff changes with the worker pool implementation can be shared
with workqueue which provides its own ways to control concurrency and
synchronize.  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.

I'm sure the cookie based synchronization has its benefits but is the
benefit big enough, or is using workqueue synchronization constructs
difficult enough to justify a completely separate synchronization
model?

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).

As for the current in-kernel users, the simplistic implementation
seems enough to me.  Do you think the stuff which is currently being
worked on would benefit a lot from cookie based synchronization
compared to using works and flushes directly?

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/