qemu-s390x
[Top][All Lists]
Advanced

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

Re: [qemu-s390x] [PATCH v1 for-2-12 06/15] s390x/flic: factor out inject


From: Christian Borntraeger
Subject: Re: [qemu-s390x] [PATCH v1 for-2-12 06/15] s390x/flic: factor out injection of floating interrupts
Date: Wed, 13 Dec 2017 11:05:10 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0


On 12/13/2017 10:31 AM, David Hildenbrand wrote:
> On 13.12.2017 10:16, Christian Borntraeger wrote:
>>
>>
>> On 12/12/2017 04:28 PM, Cornelia Huck wrote:
>>> On Tue, 12 Dec 2017 16:17:17 +0100
>>> David Hildenbrand <address@hidden> wrote:
>>>
>>>> On 12.12.2017 15:29, Cornelia Huck wrote:
>>>>> On Tue, 12 Dec 2017 15:13:46 +0100
>>>>> Christian Borntraeger <address@hidden> wrote:
>>>>>   
>>>>>> On 12/12/2017 02:49 PM, Cornelia Huck wrote:  
>>>>>   
>>>>>>> One thing I noticed: You removed the caching of the flic (in the old
>>>>>>> kvm inject routine), and you generally do more qom invocations (first,
>>>>>>> to find the common flic; then, to translate to the qemu or kvm flic).
>>>>>>> Not sure if this might be a problem (probably not).    
>>>>>>
>>>>>> Is any of these calls on a potential fast path (e.g. guest without 
>>>>>> adapter
>>>>>> interrupts)? If yes, then QOM is a no-go since it is really slow.  
>>>>>
>>>>> At least the new airq interface was using QOM without caching before.
>>>>>
>>>>> It's basically about any interrupt; but otoh we are (for kvm) in
>>>>> userspace already. Caching the flic and just keeping the casting to the
>>>>> specialized flic might be ok (I'd guess that the lookup is the slowest
>>>>> path.)
>>>>>   
>>>>
>>>> Please note that the lookup is already cached in s390_get_flic(); That
>>>> should be sufficient, as it does the expensive lookup. One cache should
>>>> be enough, no?
>>>
>>> Ah, missed that. So the old code actually did double caching...
>>>
>>>>
>>>> The other conversions should be cheap (and already were in place in a
>>>> couple of places before).
>>>
>>> Yes, object_resolve_path() is probably the most expensive one.
>>>
>>> Did anyone ever check if the (existing) conversions are actually
>>> measurable?
>>
>> Did some quick measurement.
>> the initial object resolve takes about 20000ns, the cached ones then is 
>> 2-5ns.
>> (measuring s390_get_flic function).
>>
>>
>> The other conversions (S390FLICStateClass *fsc = 
>> S390_FLIC_COMMON_GET_CLASS(fs);)
>> takes about 15-25ns (up to 100 cycles). 
>> For irqfd users this does not matter, but things like plan9fs might benefit
>> if we speedup this lookup as well?
> 
> Did you also measure the state conversion like QEMU_S390_FLIC() or
> KVM_S390_FLIC() ?

somewhat between 4 and 39 ns.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]