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. -- 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
