Re: [PATCH] kvm-userspace: Make PC speaker emulation aware of in-kernel PIT

["David S. Ahern" <daahern@cisco.com>]

Anthony Liguori wrote:
> Jan Kiszka wrote:
>> Anthony Liguori wrote:
>>  
>>> Marcelo Tosatti wrote:
>>>    
>>>> Jan,
>>>>
>>>> While the patch itself looks fine, IMO it would be better to move all
>>>> of the timer handling to userspace, except the performance critical
>>>> parts,
>>>> since most of it is generic. Either periodic or one-shot timer, with:
>>>>         
>>> The reason for having the PIT in-kernel is not performance.  The PIT is
>>> not performance sensitive.
>>>     
>>
>> I think that depends. Some OSes (in some configurations) use the PIT
>> counter as clock source and/or program it regularly in one-shot mode. An
>> aging use case, but still a valid one.
>>   
> 
> I can't find the thread, but this has been discussed at length before. 
> The justification has always been for time drift correction.  If you
> crunch the numbers, even at a 1024HZ, there just aren't enough exits to
> really make a difference from a performance perspective.
> 
> Just to state it more clearly, if you assume an additional 5us to drop
> to userspace (which is absurdly high, but let's stick with it), 1024
> exits per second comes out to about 5ms which is only 0.5% in terms of
> CPU consumption.


You are considering timekeeping activities only.

RHEL4 for example reads the PIT for each gettimeofday call. For
applications that add timestamps to logging the PIT is a *HUGE* overhead
(and the PMTMR for that matter). I have one example where something like
15% of each second is wasted handling the ioport reads and writes for
get_offset_pit.

david


> 
> The APIC is quite a bit more understandable because especially with SMP,
> you can generate a very high number of interrupts per second and taking
> a drop to userspace for every EOI can be start to matter with exit rates
> in the hundreds of thousands.
> 
>>> It's because it was easier to do interrupt catch-up by pushing the PIT
>>> into the kernel which IMHO was the wrong path to go down.
>>>     
>>
>> Pushing the emulation of port 0x61 into the kernel was a mistake we now
>> have to deal with. I'm not that sure about the PIT itself.
>>   
> 
> I agree re: port 0x61.  I'm just saying that there is no point in moving
> just the non "performance critical" components to userspace as Marcelo
> suggests because the whole thing is non "performance critical".
> 
> Regards,
> 
> Anthony Liguori
> 
> -- 
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>