qemu-ppc
[Top][All Lists]
Advanced

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

Re: [Qemu-ppc] [PATCH 1.7 v2 2/2] PPC: BookE: Make FIT/WDT timers at bes


From: Tom Musta
Subject: Re: [Qemu-ppc] [PATCH 1.7 v2 2/2] PPC: BookE: Make FIT/WDT timers at best millisecond grained
Date: Mon, 02 Dec 2013 13:37:37 -0600
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1

On 12/2/2013 11:08 AM, Alexander Graf wrote:
> 
> On 02.12.2013, at 17:50, Tom Musta <address@hidden> wrote:
> 
>> On 11/25/2013 3:46 PM, Alexander Graf wrote:
>>> The default granularity for the FIT timer on 440 is on every 0x1000th
>>> transition of TB from 0 to 1. Translated that means 48828 times a second.
>>>
>>> Since interrupts are quite expensive for 440 and we don't really care
>>> about the accuracy of the FIT to that significance, let's force FIT and
>>> WDT to at best millisecond granularity.
>>>
>>> This basically restores behavior as it was in QEMU 1.6, where timers
>>> could only deal with millisecond granularities at all.
>>>
>>> This patch greatly improves performance with the 440 target and restores
>>> roughly the same performance level that QEMU 1.6 had for me.
>>>
>>
>> @Reviewed-by: Tom Musta <address@hidden>
>>
>> Alexander:
>>
>> Is the problem the default?  If so, would it be better to change the default?
>> (for example, set the default TCR_FP for the 440 to 0b10).  Of course, if 
>> your
>> software is setting this back to 0b00, you will still have a problem.
> 
> Well, we set the TCR_FP value to what hardware defines it to be in on reset 
> :).
> 
>> The downside to your approach is that it eliminates the possibility for fine
>> grained timer interrupts for all Book E implementations and all kernels 
>> and/or
>> hypervisors.  I am not aware of any such system so my comment is purely
>> theoretical.
> 
> True. But then again you'll be too slow with all that TCG jumping in to 
> really handle these find grained timing events.
> 
> 
> Alex
> 

Alex:

It seems to me that this patch is making a practical choice to deviate from the 
hardware --
retain the POR value in the TCR but choose to not model it accurately.  
Deviating from
the POR value but retaining the ability to trigger interrupts on less than a 
one millis
interval is a just a different choice that I wanted to point out.  Take it for 
what it
is worth.

Thanks,
Tom







reply via email to

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