Hi Evengiy,

On 2/3/06, Evgeniy Polyakov <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to