On Friday 22 April 2016 15:54:56 Ulf Hansson wrote: > > > > > My suggestion with using > > > > wait_event(host->wq, !cmpxchg(host->current_req, NULL, mrq)); > > > > should sufficiently solve the problem, but the suggestion of using > > a kthread (even though not needed for taking a mutex) would still > > have some advantages and one disadvantage: > > > > + We never need to spin in the irq context (also achievable using > > a threaded handler) > > + The request callback always returns immediately after queuing up > > the request to the kthread, rather than blocking for a potentially > > long time while waiting for an operation in another slot to complete > > + it very easily avoids the problem of serialization between > > the slots, and ensures that each slot gets an equal chance to > > send the next request. > > - you get a slightly higher latency for waking up the kthread in > > oder to do a simple request (comparable amount of latency that > > is introduced by an irq thread). > > > > Currently I can't think of anything better, so I guess something along > these lines is worth a try. > > No matter what, I guess we want to avoid to use a semaphore as long as > possible, right!? Yes, I think that would be good, to avoid curses from whoever tries to eliminate them the next time. I think there is some renewed interest in realtime kernels these days, and semaphores are known to cause problems with priority inversion (precisely because you don't know which thread will release it). Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
