[lkml]   [2010]   [Jan]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 32/40] async: introduce workqueue based alternative implementation
    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

    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?



     \ /
      Last update: 2010-01-19 09:01    [W:0.024 / U:8.932 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site