On Fri, 26 Jan 2018 12:25:03 +0100 Christian Borntraeger <borntraeger@xxxxxxxxxx> wrote: > On 01/26/2018 12:21 PM, Cornelia Huck wrote: > > On Fri, 26 Jan 2018 10:57:32 +0100 > > Christian Borntraeger <borntraeger@xxxxxxxxxx> wrote: > > > >> On 01/26/2018 10:41 AM, Cornelia Huck wrote: > >>> On Thu, 25 Jan 2018 14:28:45 +0100 > >>> Christian Borntraeger <borntraeger@xxxxxxxxxx> wrote: > >>> > >>>> From: Michael Mueller <mimu@xxxxxxxxxxxxxxxxxx> > >>>> > >>>> The function returns a pending I/O interrupt with the highest > >>>> priority defined by its ISC. > >>>> > >>>> Together with AIV activation, pending adapter interrupts are > >>>> managed by the GISA IPM. Thus kvm_s390_get_io_int() needs to > >>>> inspect the IPM as well when the interrupt with the highest > >>>> priority has to be identified. > >>>> > >>>> In case classic and adapter interrupts with the same ISC are > >>>> pending, the classic interrupt will be returned first. > >>> > >>> Can this lead to starving? Consider a guest that never enables itself > >>> for I/O interrupts, but collects pending interrupts via tpi. It will > >>> always get the intis for an isc, but not the ai, wouldn't it? > >> > >> Only if it handles the interrupts slower than new ones arrive, in that case > >> you have a problem anyway. When looking at sane configuration, this priority > >> makes sense as the classic interrupts are used for configuration type ccw, > >> while adapter interrupts are for data. You want to get the control changes > >> quickly. In a sane environment nobody would probably put devices with adapter > >> interrupts on the same isc as different devices with only classic interrupts. > > > > But if you have a lot of devices, all using the same isc, you might > > have a lot of classic interrupts (for example, due to firing a volley > > of channel programs at all subchannels) and they could starve out the > > device(s) that are waiting for adapter interrupts. > > > > It's probably not a problem with today's guests (due to the control vs. > > data semantics you pointed out above), especially as the only guest I > > know that does not enable interrupts is the s390-ccw bios. But maybe > > add a comment? > > Do you have some proposal for a comment? Then I can certainly add that. > /* * Note that for a guest that does not enable I/O interrupts * but relies on TPI, a flood of classic interrupts may starve * out adapter interrupts on the same isc. Linux does not do * that, and it is possible to work around the issue by configuring * different iscs for classic and adapter interrupts in the guest, * but we may want to revisit this in the future. */ I think we don't really need to spend more time on that right now (and probably complicate the code), so with the comment Reviewed-by: Cornelia Huck <cohuck@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-s390" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
