Re: [PATCH 04/10] KVM: s390: add metric vcpus_in_sie to struct kvm_arch

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

 




On 11/07/2018 10:52 PM, Pierre Morel wrote:
>>>>> Mimu, we just spoke about -- thus a reminder for us, and a FYI for
>>>>> the rest. vcpus_in_sie != 0 does not necessarily mean that FW can
>>>>> deliver GISA interrupts to the guest (and thus we don't have to
>>>>> dispatch a suitable vcpu): if all cpus in SIE mask IO interrupts it
>>>>> does not really matter that they are in SIE. I.e. we should still get
>>>>> alerted and try to dispatch an eligible vcpu.
>>>
>>> If I understood well, I do not agree.
>>
>> I don't think you understood well.
>>
>>> If all the vCPU have ISC masked in CR6 we do not need to dispatch the vCPU, running or not.
>>> If running,
>>> The first vCPU that will load CR6 with at least one bit of the ISC being one will be scheduled by the firmware.
>>>
>>
>> Let me help you with an example. Our guest has 3 vCPUs. One (CPU1) of those is doing something
>> very important real-time-ish stuff and is currently in SIE with all maskable interrupts
>> shut off (the stuff is very important). The other two vCPUs (CPU2 and CPU3) are open for IO
>> interrupts but idle, that is not in SIE.
>>
>> AFAIU we should opt for getting alerted and kicking CPU2 or CPU3 in this case, as we can
>> not assume that CPU1 will open up for interrupts any time soon. I read your text like,
>> you think we can make that assumption. Did I misunderstand you? If not, why do you think
>> we can make that assumption?
> 
> OK, I undertand, you want to make an optimization and kick one idle CPU not having the interrupt masked.
> Seems right for me, but I think we could implement this later.

I'm not sure if it is just an optimization or not. If we don't have another mechanism that
will kick one of the two form the example, the guest will loose initiative. And that is a bug
because it could wait for the IRQ forever. If we do have a different mechanism that we are going to
keep on relying, then everything we do around GIB is just an optimization in the same sense
as the point under discussion. I have not looked enough at the proposed code to tell if guest
looses initiative or not.

Important thing is we are roughly on the same page I think.

Regards,
Halil




[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