On Wed, 19 Sep 2018 15:17:28 +0200 Halil Pasic <pasic@xxxxxxxxxxxxx> wrote: > On 09/18/2018 08:45 PM, Cornelia Huck wrote: > > We basically have two options: > > - Have a way to queue I/O operations and then handle them in sequence. > > Creates complexity, and is likely overkill. (We already have a kind > > of serialization because we re-submit the channel program until the > > hypervisor accepts it; the problem comes from the wait queue usage.) > > I secretly hoped we already have something like this somewhere. Getting > some kind of requests processed and wanting to know if each of these worked > or not seemed like fairly common. I agree, implementing this just for > virtio-ccw would be an overkill, I agree. I've encountered that pattern so far mostly for driver-internal I/O (setting some stuff up via channel commands etc.) Other usages (like e.g. the dasd driver processing block layer requests) are asynchronous, and the common I/O layer uses a full-fledged fsm. Much of the trouble comes from implementing a synchronous interface via asynchronous commands, and I'd really like to keep that as simple as possible (especially as this is not the hot path). > > > - Add serialization around the submit/wait procedure (as you did), but > > with a per-device mutex. That looks like the easiest solution. > > > > Yep, I'm for doing something like this first. We can think about doing > something more elaborate later. I will send a non-RFC with an extra > per-device mutex. Unless you object. No, that sounds good to me. > > Another thought that crossed my head was making the transport ops > mutex on each virtio-ccw device -- see our conversation on get/set > config. I don't think it would make a big difference, since the > ccw stuff is mutex already, so we only have parallelism for the > preparation and for post-processing the results of the ccw io. Do you spot any other places where we may need to care about concurrent processing (like for the ->config area in the previous patch)?
