Andi Kleen wrote:
>> I once had some code in there to do that, implemented in very boneheaded
>> way with a spinlock to protect the "last time returned" variable. I
>> expect there's a better way to implement it.
>>
>
> But any per CPU setup likely needs this to avoid non monotonicity
Yeah.
On 6/6/07 13:46, "Jan Beulich" <[EMAIL PROTECTED]> wrote:
>> On the other hand some timing issues on throttling are probably
>> the smallest of the users' problems when it really happens.
>
> Not if this results in your box hanging - I think throttling is exactly
> intended
> to keep the box a
On Wednesday 06 June 2007 14:46:59 Jan Beulich wrote:
> >>> Andi Kleen <[EMAIL PROTECTED]> 06.06.07 14:18 >>>
> >
> >>
> >> Yes, this could be an issue. Is there any way to get an interrupt or MCE
> >> when thermal throttling occurs?
> >
> >Yes you can get an thermal interrupt from the local APIC.
>>> Andi Kleen <[EMAIL PROTECTED]> 06.06.07 14:18 >>>
>
>>
>> Yes, this could be an issue. Is there any way to get an interrupt or MCE
>> when thermal throttling occurs?
>
>Yes you can get an thermal interrupt from the local APIC. See the Linux
>kernel source. Of course there would be still a race
>
> Yes, this could be an issue. Is there any way to get an interrupt or MCE
> when thermal throttling occurs?
Yes you can get an thermal interrupt from the local APIC. See the Linux
kernel source. Of course there would be still a race window.
On the other hand some timing issues on throttling
On 6/6/07 12:00, "Jan Beulich" <[EMAIL PROTECTED]> wrote:
>> If the error across CPUS is +/- just a few microseconds at worst then having
>> the clocksource clamp to no less than the last timestamp returned seems a
>> reasonable fix. Time won't 'stop' for longer than the cross-CPU error, and
>>
>>> Keir Fraser <[EMAIL PROTECTED]> 06.06.07 11:56 >>>
>On 6/6/07 10:30, "Jan Beulich" <[EMAIL PROTECTED]> wrote:
>
>>> If you have an ACPI PM timer in your system (and if you have SMM then your
>>> system is almost certainly modern enough to have one) then surely the
>>> problem is fixed for all p
On Wednesday 06 June 2007 12:05:22 Jeremy Fitzhardinge wrote:
> Jan Beulich wrote:
> > Xen itself knows to deal with this (by using an error correction factor to
> > slow down the local [TSC-based] clock), but for the kernel such a situation
> > may be fatal: If clocksource->cycle_last was most rec
>> But I think that a clock source can be expected to be
>> monotonic anyway, which Xen's interpolation mechanism doesn't
>> guarantee across multiple CPUs. (I'm actually beginning to think that
>> this might also be the reason for certain test suites occasionally reporting
>> timeouts to fire ear
Jan Beulich wrote:
> Xen itself knows to deal with this (by using an error correction factor to
> slow down the local [TSC-based] clock), but for the kernel such a situation
> may be fatal: If clocksource->cycle_last was most recently set on a CPU
> with shadow->tsc_to_nsec_mul sufficiently differe
On 6/6/07 10:30, "Jan Beulich" <[EMAIL PROTECTED]> wrote:
>> If you have an ACPI PM timer in your system (and if you have SMM then your
>> system is almost certainly modern enough to have one) then surely the
>> problem is fixed for all practical purposes? The problem was overflow of a
>> fixed-wi
>>> Keir Fraser <[EMAIL PROTECTED]> 06.06.07 10:54 >>>
>On 6/6/07 09:39, "Jan Beulich" <[EMAIL PROTECTED]> wrote:
>
>> The issue is
>> that on that system, transition into ACPI mode takes over 600ms (SMM
>> execution, and hence no interrupts delivered during that time), and with
>> Xen using the PI
On 6/6/07 09:39, "Jan Beulich" <[EMAIL PROTECTED]> wrote:
> The issue is
> that on that system, transition into ACPI mode takes over 600ms (SMM
> execution, and hence no interrupts delivered during that time), and with
> Xen using the PIT (PM timer support was added by Keir as a result of this,
>
>+cycle_t xen_clocksource_read(void)
>+{
>+ struct shadow_time_info *shadow = &get_cpu_var(shadow_time);
>+ cycle_t ret;
>+
>+ get_time_values_from_xen();
>+
>+ ret = shadow->system_timestamp + get_nsec_offset(shadow);
>+
>+ put_cpu_var(shadow_time);
>+
>+ return ret;
14 matches
Mail list logo
