Re: [PATCH v2 01/12] KVM: s390: leave AIs in IPM of GISA during vcpu_pre_run()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 20 Nov 2018 22:03:59 +0100
Christian Borntraeger <borntraeger@xxxxxxxxxx> wrote:

> On 11/20/2018 12:33 PM, Cornelia Huck wrote:
> > On Mon, 19 Nov 2018 18:25:25 +0100
> > Michael Mueller <mimu@xxxxxxxxxxxxx> wrote:
> >   
> >> Do not call __deliver_io() for adapter interruptions already
> >> pending in the IPM. That is a double effort. They will
> >> be processed as soon the vcpu control is given to SIE.
> >>
> >> Signed-off-by: Michael Mueller <mimu@xxxxxxxxxxxxx>
> >> ---
> >>  arch/s390/kvm/interrupt.c | 54 ++++++++++++++++++++++-------------------------
> >>  1 file changed, 25 insertions(+), 29 deletions(-)  
> > 
> > I think this patch does what it says on the tin, but I'm a bit lost as
> > to the why. (Might make more sense with the gib.)
> > 
> > Currently, we are trying to process any I/O interrupts, even if we'd
> > get them delivered via the gisa, when we're out of the SIE anyway.
> > IIRC, while this looks a bit like a belt-and-suspenders approach, it
> > also prevented performance problems when the vcpu did not go back into
> > the SIE immediately (it even may exit to userspace  
> 
> In fact, doing the inject when in SIE is likely better performance-wise.
> Right now we "inject" the floating interrupt and then we handle 
> the requests. That can actually mean that it could take a while 
> until the interrupt is actually noticed by the guest (when
> in SIE). If you now have a 2nd CPU enabled this interrupt could
> have been delivered to the guest much earlier but it is "stuck" in
> the local CPU.

Hm, yes. Do we see any different effects if we have a guest with only
one cpu (or only one cpu enabled for I/O interrupts?) Or does all of
this even out in practice?

> > Also, if you're ignoring the I/O interrupts pending in the ipm, you may
> > end up delivering interrupts with a lower priority (higher isc) first.
> > I'm not sure that's what we want.  
> 
> FWIW, LPAR has the same relaxation regarding priorities of subclasses.

Interesting to know, thanks. What about restart etc. interrupts, as
David has noted?



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Kernel Development]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Info]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Linux Media]     [Device Mapper]

  Powered by Linux