Date: Thu, 23 Jun 2011 19:55:55 +0300 From: Alexander Motin <mav@FreeBSD.org> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r223426 - in head/sys: dev/acpica kern sys x86/x86 Message-ID: <4E03701B.8090103@FreeBSD.org> In-Reply-To: <6D159261-7C57-4509-B41B-E440DBB4CBEA@xcllnt.net> References: <201106221640.p5MGejHY057164@svn.freebsd.org> <4E021C8E.8010904@FreeBSD.org> <201106221455.07540.jkim@FreeBSD.org> <201106221924.50458.jkim@FreeBSD.org> <D269F433-17DB-4976-BA6F-2BB31527E691@xcllnt.net> <4E028921.2040805@FreeBSD.org> <8B9DCBA3-C3EC-43EE-8BEC-858A280A2096@xcllnt.net> <4E02989F.6040703@FreeBSD.org> <6D159261-7C57-4509-B41B-E440DBB4CBEA@xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Marcel Moolenaar wrote: > On Jun 22, 2011, at 6:36 PM, Alexander Motin wrote: >> Marcel Moolenaar wrote: >>> On Jun 22, 2011, at 5:30 PM, Alexander Motin wrote: >>>> Marcel Moolenaar wrote: >>>>> On Jun 22, 2011, at 4:24 PM, Jung-uk Kim wrote: >>>>>> I just realized kern_clocksource.c was excluded for arm and ia64. >>>>>> Here is updated patch. Please ignore the previous one. >>>>> Any reason why we're not adding kern_clocksource.c for them? >>>> Their event timers code still waits for refactoring. I have neither >>>> documentation nor hardware for them. Help would be appreciated. >>> Can you give me a pointer to a document orpage that describes >>> what is being refactored, why and how? >> In short, timer management code was unified and formalized. Instead of >> direct programming periodic timers from MD code and calling hard-/ >> stat-/ profclock() from there, timer hardware should be exposed to the >> MI kernel using sys/timeet.h API to allow kern_clocksource.c manage it. >> Last require calling its cpu_initclocks_bsp() and cpu_initclocks_ap() >> callbacks from MD initialization code, and cpu_idleclock() and >> cpu_activeclock() from MD cpu_idle(). >> >> Here is some references: >> man 4 eventtimers >> http://wiki.freebsd.org/201010DevSummit?action=AttachFile&do=view&target=timers.pdf >> http://svnweb.freebsd.org/base?view=revision&revision=209371 >> http://svnweb.freebsd.org/base?view=revision&revision=212541 >> >> All architectures except ia64 and non-Marvell arm are already done, so >> you may took any of them as reference. Ask me if you have any questions. > > Can you give a quick outline of how all the various clock > related initializations and support code relate, interact > or even conflict? It's getting rather convoluted and want > to make sure I get the ordering and timing right. During probe, every event timer driver initializes hardware and calls et_register(). After probe done, on SI_SUB_CLOCKS SYSINIT stage MI cpu_initclocks_bsp() called from MD cpu_initclocks() chooses the best timer, chooses best hz, stathz and profhz values according to timer capabilities and starts timer. If timer is per-CPU, it starts only BSP one. Later, on SMP APs startup, when each CPU launched, cpu_initclocks_ap() is called to start per-CPU timers there. MI code no longer calls hard-/stat-/profclock(). Instead it calls registered callback function. Callback function expects to be called in hardware interrupt context: td_intr_nesting_level should be incremented and td_intr_frame should contain interrupt trapframe pointer. You may see lapic_handle_timer() in x86/x86/local_apic.c as workaround example, if needed. cpu_startprofclock() and cpu_stopprofclock() are MI now and should be removed from MD code. MI cpu_idleclock() and cpu_activeclock() should be called from MD cpu_idle() on per-CPU basis to reprogram timer when CPU enters/exits sleep state. They should be called within critical section to delay context switch on wakeup until all skipped during sleep time events are handled (by the cpu_activeclock()). Timer calls are serialized by caller by holding spin lock (per-CPU locks for per-CPU timers). Due to disabled interrupts, you are not allowed to sleep, wait for IPIs delivery or do anything else, that may cause deadlock with other CPUs. Depending on hardware implementation, you may need to take care to not loose events on short time intervals. It is especially important in one-shot mode, as timer won't be reloaded in that case. > Also: The ITC on ia64 is a per-CPU, one short and periodic > timer that has a fixed frequency. Though the architecture > does not guarantee that counters are synchronized, nor > that all CPUs in a system run at the same frequency which > means that the ITCs may not all run at the same frequency. > Does the et code work with that or do I need to impose a > restriction on what hardware configurations to support > and/or revert to having the ITC be a global timer and run > only on the BSP? Event timer API operates in terms of bintime time intervals. It doesn't depend on timer base frequency. kern_clocksource.c uses that frequency only to calculate more suitable hz/stathz/profhz values. It will survive wrong value there, or even zero, if frequency is unknown. If base frequency differs between CPUs, event timer driver should just properly handle requested bintime value, using proper base frequency when programming timer. In one-shot mode kern_clocksource.c doesn't depend on timer precision. In periodic mode it does, but some drift between CPUs is acceptable. -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E03701B.8090103>