DragonFly commits List (threaded) for 2009-05
DragonFly BSD
DragonFly commits List (threaded) for 2009-05
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: DragonFly-2.3.0.864.gc5b83 master sys/platform/pc32/apic mpapic.c sys/platform/pc32/isa clock.c sys/platform/pc64/isa clock.c sys/platform/vkernel/platform systimer.c sys/sys systimer.h


From: Sepherosa Ziehau <sepherosa@xxxxxxxxx>
Date: Tue, 5 May 2009 09:42:59 +0800

On Mon, May 4, 2009 at 11:29 PM, Matthew Dillon
<dillon@apollo.backplane.com> wrote:
>
> :>    Then on entry to C3/C1E the ACPI code could explicitly call
> :>    cputimer_intr_sleep_reload(), and on exit it could explicitly
> :
> :Implicitly?
> :
> :>    resynchronize the LAPIC like it does already (I think).
>
>    It may not be relevant if you are going to change the
>    acpi_cpu_idle() code to just leave the LAPIC installed as
>    the official cpu timer instead of calling cputimer_intr_switch()
>    to switch things back and forth.

To be safe, we will have to do an explicit reload :)

>
>    For an 8254-based wakeup you would probably want to maintain
>    a global cpu mask of cpu's sitting in sleep that need to be
>    IPId (instead of IPI'ing all of them), and interlock the updating
>    of the 8254's one-shot & notification cpumask with the same spinlock
>    the 8254 code uses now (clock_lock()).

Would it necessary to use clock_lock()?  I think if the mask is only
set/clear in acpi_idle, atomic operation should be enough.

>
>    There are a lot of things that could be causing excessive interrupts
>    on a multi-cpu platform, the code is going to be quite sensitive.
>
>                                        -Matt
>                                        Matthew Dillon
>                                        <dillon@backplane.com>
>



-- 
Live Free or Die



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