Hi Evengiy, On 2/3/06, Evgeniy Polyakov <johnpol@xxxxxxxxxxx> wrote: > I have some comments about asynchronous usage of adma_queue_desc(), > adma_run(eng) and adma_spin_wait(). > > Existense of adma_spin_wait() is a sign of tricky bugs in near future, > since it hurts performance by busy loop and creates possibility to catch a race, > if busy flag will be set/cleared in the way adma_spin_wait() will not > see it. > > I would recommend to modify state machine in async md_raid and eliminate > adma_spin_wait() completely. > > In acrypto crypto provider can specially mark crypto_session (descriptor in your case) > so when provider calls queueing mechanism (adma_queue_desc() in your case) > session is not queued but processed immediately(adma_run()), so there is no need in busy waiting. > > Btw, as optimisation step, it is very usefull sometimes (if queueing > context allows to sleep) to call needed callbacks directly and do not > postpone work to be done by thread. Thanks for the feedback, I will implement these changes. Also, now that you have given me some hints as to the acrypto vocabulary, I can start looking into integration and cross pollenation efforts. Dan - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html