[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