summaryrefslogtreecommitdiffstats
path: root/sys/kern/kern_clocksource.c
Commit message (Collapse)AuthorAgeFilesLines
* MFC r312551:hselasky2017-03-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix for race leading to endless timer interrupts related to configtimer(). During normal operation "state->nextcallopt" will always be less than or equal to "state->nextcall" and checking only "state->nextcallopt" before calling "callout_process()" is sufficient. However when "configtimer()" is called a race might happen requiring both of these binary times to be checked. Short description of race: 1) A configtimer() call will reset both "state->nextcall" and "state->nextcallopt" to the same binary time. 2) If a "callout_reset()" call happens between "configtimer()" and the next "callout_process()" call, "state->nextcallopt" will get updated and "state->nextcall" will remain at the current time. Refer to logic inside cpu_new_callout(). 3) getnextcpuevent() only respects "state->nextcall" and returns this value over and over again, even if it is in the past, until "now >= state->nextcallopt" becomes true. Then these two time variables are corrected by a "callout_process()" call and the situation goes back to normal. The problem manifests itself in different ways. The common factor is the timer process(es) consume all CPU on one or more CPU cores for a long time, blocking other kernel processes from getting execution time. This can be seen by very high interrupt counts as displayed by "vmstat -i | grep timer" right after boot. When EARLY_AP_STARTUP was enabled in r310177 the likelyhood of hitting this bug apparently increased. Example output from "vmstat -i" before patch: cpu0:timer 7591 69 cpu9:timer 39031773 358089 cpu4:timer 9359 85 cpu3:timer 9100 83 cpu2:timer 9620 88 Example output from "vmstat -i" after patch: cpu0:timer 4242 34 cpu6:timer 5531 44 cpu3:timer 6450 52 cpu1:timer 4545 36 cpu9:timer 7153 58 Before the patch cpu9 in the example above, was spinning in a loop in order to reach 39 million interrupts just a few seconds after bootup. After the patch the timer interrupt counts are more or less consistent. Discussed with: mav @ Reported by: several people Sponsored by: Mellanox Technologies
* MFC r264388 (by davide):kib2016-08-271-4/+4
| | | | | | | | | | | | | Define SBT_MAX. MFC r267896 (by davide): Improve r264388. MFC note. The SBT_MAX definition already existed on stable/10, but without the refinement from r267896. Also, consumers of SBT_MAX were not converted, since r264388 was not merged properly. Reviewed by: mav
* MFC r275576: remove opensolaris cyclic code, replace with high-precision ↵avg2015-05-111-57/+0
| | | | callouts
* MFC 276724:jhb2015-04-021-5/+6
| | | | | | | | | | On some Intel CPUs with a P-state but not C-state invariant TSC the TSC may also halt in C2 and not just C3 (it seems that in some cases the BIOS advertises its C3 state as a C2 state in _CST). Just play it safe and disable both C2 and C3 states if a user forces the use of the TSC as the timecounter on such CPUs. PR: 192316
* MFC r278209:kib2015-02-111-0/+39
| | | | Add ddb command 'show clocksource'.
* MFC 264019, 264041, 264048, 264049, 264050, 264051ian2014-05-171-0/+19
| | | | | | | | | | | | | | Add support for event timers whose clock frequency can change while running. Apparently all ARM configs build kern_et.c, but only a few of them also build kern_clocksource.c, un-break the build by not referencing functions in kern_clocksource if NO_EVENTTIMERS is defined. Add variable-frequency support to the arm mpcore eventtimer driver. mpcore_timer: Disable the timer and clear any pending bit, then setup the new counter register values, then restart the timer. Also re-nest the parens properly for casting the result of converting time and frequency to a count.
* MFC r259464:mav2014-01-031-1/+2
| | | | Fix periodic per-CPU timers startup on boot.
* - Make callout(9) tickless, relying on eventtimers(4) as backend fordavide2013-03-041-250/+218
| | | | | | | | | | | | | | | | | | | | | | | | | | | precise time event generation. This greatly improves granularity of callouts which are not anymore constrained to wait next tick to be scheduled. - Extend the callout KPI introducing a set of callout_reset_sbt* functions, which take a sbintime_t as timeout argument. The new KPI also offers a way for consumers to specify precision tolerance they allow, so that callout can coalesce events and reduce number of interrupts as well as potentially avoid scheduling a SWI thread. - Introduce support for dispatching callouts directly from hardware interrupt context, specifying an additional flag. This feature should be used carefully, as long as interrupt context has some limitations (e.g. no sleeping locks can be held). - Enhance mechanisms to gather informations about callwheel, introducing a new sysctl to obtain stats. This change breaks the KBI. struct callout fields has been changed, in particular 'int ticks' (4 bytes) has been replaced with 'sbintime_t' (8 bytes) and another 'sbintime_t' field was added for precision. Together with: mav Reviewed by: attilio, bde, luigi, phk Sponsored by: Google Summer of Code 2012, iXsystems inc. Tested by: flo (amd64, sparc64), marius (sparc64), ian (arm), markj (amd64), mav, Fabian Keil
* MFcalloutng:mav2013-02-281-7/+9
| | | | | | | Switch eventtimers(9) from using struct bintime to sbintime_t. Even before this not a single driver really supported full dynamic range of struct bintime even in theory, not speaking about practical inexpediency. This change legitimates the status quo and cleans up the code.
* MFcalloutng:davide2013-02-281-2/+4
| | | | | | | | | | | When CPU becomes idle, cpu_idleclock() calculates time to the next timer event in order to reprogram hw timer. Return that time in sbintime_t to the caller and pass it to acpi_cpu_idle(), where it can be used as one more factor (quite precise) to extimate furter sleep time and choose optimal sleep state. This is a preparatory change for further callout improvements will be committed in the next days. The commmit is not targeted for MFC.
* Add support for good old 8192Hz profiling clock to software PMC.mav2013-02-261-9/+15
| | | | Reviewed by: fabient
* Get time of next event from other cores only if SMP is already started.gber2013-02-011-8/+10
| | | | | Reviewed by: mav Obtained from: Semihalf
* panic() with reasonable message instead of returning zero frequency causingmav2012-10-101-1/+2
| | | | | | | division by zero later if event timer's minimal period is above one second. For now it is just a theoretical possibility. Found by: Clang Static Analyzer
* Particlly MFcalloutng r238425 (by davide):mav2012-08-041-11/+6
| | | | | | | | | Fix an issue related to old periodic timers. The code in kern_clocksource.c uses interrupt to keep track of time, and this time may not match with binuptime(). In order to address such incoherency, switch periodic timers to binuptime(). Except further calloutng it is needed for already present cyclic subsystem.
* Partialy MFcalloutng r236894 (by davide):mav2012-08-041-20/+20
| | | | | | ... While here, Bruce Evans told me that "unsigned int" is spelled "u_int" in KNF, so replace it where needed.
* Microoptimize time math. As soon as our event periods are always below omemav2012-08-031-12/+14
| | | | | second we may not add intereger parts by using bintime_addx() instead of bintime_add(). Profiling shows handleevents() time redction by 15%.
* Add kern.eventtimer.activetick tunable/sysctl, specifying whether eachmav2012-03-131-8/+24
| | | | | | | | | | | | | | | | | | | hardclock() tick should be run on every active CPU, or on only one. On my tests, avoiding extra interrupts because of this on 8-CPU Core i7 system with HZ=10000 saves about 2% of performance. At this moment option implemented only for global timers, as reprogramming per-CPU timers is too expensive now to be compensated by this benefit, especially since we still have to regularly run hardclock() on at least one active CPU to update system uptime. For global timer it is quite trivial: timer runs always, but we just skip IPIs to other CPUs when possible. Option is enabled by default now, keeping previous behavior, as periodic hardclock() calls are still used at least to implement setitimer(2) with ITIMER_VIRTUAL and ITIMER_PROF arguments. But since default schedulers don't depend on it since r232917, we are much more free to experiment with it. MFC after: 1 month
* Idle ticks optimization:mav2012-03-101-6/+12
| | | | | | | | | | | - Pass number of events to the statclock() and profclock() functions same as to hardclock() before to not call them many times in a loop. - Rename them into statclock_cnt() and profclock_cnt(). - Turn statclock() and profclock() into compatibility wrappers, still needed for arm. - Rename hardclock_anycpu() into hardclock_cnt() for unification. MFC after: 1 week
* Be more polite when setting state->nextevent inside cpu_new_callout().mav2012-03-091-2/+3
| | | | | | Hardclock is not the only who wakes idle CPU since kdtrace cyclic addition. MFC after: 2 weeks
* Set negative quality to TSC timecounter when C3 state is enabled for Inteljkim2011-06-221-0/+1
| | | | | | | | | | | | | | | processors unless the invariant TSC bit of CPUID is set. Intel processors may stop incrementing TSC when DPSLP# pin is asserted, according to Intel processor manuals, i. e., TSC timecounter is useless if the processor can enter deep sleep state (C3/C4). This problem was accidentally uncovered by r222869, which increased timecounter quality of P-state invariant TSC, e.g., for Core2 Duo T5870 (Family 6, Model f) and Atom N270 (Family 6, Model 1c). Reported by: Fabian Keil (freebsd-listen at fabiankeil dot de) Ian FREISLICH (ianf at clue dot co dot za) Tested by: Fabian Keil (freebsd-listen at fabiankeil dot de) - Core2 Duo T5870 (C3 state available/enabled) jkim - Xeon X5150 (C3 state unavailable)
* better integrate cyclic module with clocksource/eventtimer subsystemavg2011-05-161-12/+61
| | | | | | | | | | Now in the case when one-shot timers are used cyclic events should fire closer to theier scheduled times. As the cyclic is currently used only to drive DTrace profile provider, this is the area where the change makes a difference. Reviewed by: mav (earlier version, a while ago) X-MFC after: clocksource/eventtimer subsystem
* Refactor Xen PV code to use new event timers subsystem. That uses one-shotmav2011-05-131-5/+0
| | | | | | | | | | | Xen timer and time counter to provide one-shot and periodic time events. On my tests this reduces idle interruts rate down to about 30Hz, and accor- ding to Xen VM Manager reduces host CPU load by three times comparing to the previous periodic 100Hz clock. Also now, when needed, it is possible to increase HZ rate without useless CPU burning during idle periods. Now only ia64 and some ARMs left not migrated to the new event timers.
* sysctl(9) cleanup checkpoint: amd64 GENERIC builds cleanly.mdf2011-01-121-1/+1
| | | | Commit the kernel changes.
* After some off-list discussion, revert a number of changes to thedim2010-11-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | DPCPU_DEFINE and VNET_DEFINE macros, as these cause problems for various people working on the affected files. A better long-term solution is still being considered. This reversal may give some modules empty set_pcpu or set_vnet sections, but these are harmless. Changes reverted: ------------------------------------------------------------------------ r215318 | dim | 2010-11-14 21:40:55 +0100 (Sun, 14 Nov 2010) | 4 lines Instead of unconditionally emitting .globl's for the __start_set_xxx and __stop_set_xxx symbols, only emit them when the set_vnet or set_pcpu sections are actually defined. ------------------------------------------------------------------------ r215317 | dim | 2010-11-14 21:38:11 +0100 (Sun, 14 Nov 2010) | 3 lines Apply the STATIC_VNET_DEFINE and STATIC_DPCPU_DEFINE macros throughout the tree. ------------------------------------------------------------------------ r215316 | dim | 2010-11-14 21:23:02 +0100 (Sun, 14 Nov 2010) | 2 lines Add macros to define static instances of VNET_DEFINE and DPCPU_DEFINE.
* Apply the STATIC_VNET_DEFINE and STATIC_DPCPU_DEFINE macros throughoutdim2010-11-141-1/+1
| | | | the tree.
* On APs startup skip hard-/statclock events, which time passed before CPUmav2010-11-081-16/+30
| | | | | was lauched. Few seconds event burst, accumulated during long startup, reported to cause panic in SCHED_ULE priority calculation logic.
* If kernel built with DEVICE_POLLING, keep one CPU always in active statemav2010-09-221-1/+6
| | | | to handle it.
* If new callout scheduled to another CPU and we are using global timer,mav2010-09-211-3/+7
| | | | | there is high probability that timer is already programmed by some other CPU. Especially by one that registered this callout, and so active now.
* Remember last kern.eventtimer.periodic value, explicitly set by user.mav2010-09-211-2/+5
| | | | | | If timer capabilities forcing us to change periodicity mode, try to restore it back later, as soon as new choosen timer capable to do it. Without this, timer change like HPET->RTC->HPET always results in enabling periodic mode.
* When global timer used at SMP system, update nextevent field on BSP beforemav2010-09-181-4/+4
| | | | | | sending IPI to other CPUs. Otherwise, other CPUs will try to honor stale value, programming timer for zero interval. If timer is fast enough, it caused extra interrupt before timer correctly reprogrammed by BSP.
* Make kern_tc.c provide minimum frequency of tc_ticktock() calls, requiredmav2010-09-141-1/+5
| | | | | | to handle current timecounter wraps. Make kern_clocksource.c to honor that requirement, scheduling sleeps on first CPU for no more then specified period. Allow other CPUs to sleep up to 1/4 second (for any case).
* Add some foot shooting protection by checking singlemul value correctness.mav2010-09-141-4/+5
| | | | | | Rephrase sysctls descriptions. Suggested by: edmaste
* Refactor timer management code with priority to one-shot operation mode.mav2010-09-131-262/+601
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The main goal of this is to generate timer interrupts only when there is some work to do. When CPU is busy interrupts are generating at full rate of hz + stathz to fullfill scheduler and timekeeping requirements. But when CPU is idle, only minimum set of interrupts (down to 8 interrupts per second per CPU now), needed to handle scheduled callouts is executed. This allows significantly increase idle CPU sleep time, increasing effect of static power-saving technologies. Also it should reduce host CPU load on virtualized systems, when guest system is idle. There is set of tunables, also available as writable sysctls, allowing to control wanted event timer subsystem behavior: kern.eventtimer.timer - allows to choose event timer hardware to use. On x86 there is up to 4 different kinds of timers. Depending on whether chosen timer is per-CPU, behavior of other options slightly differs. kern.eventtimer.periodic - allows to choose periodic and one-shot operation mode. In periodic mode, current timer hardware taken as the only source of time for time events. This mode is quite alike to previous kernel behavior. One-shot mode instead uses currently selected time counter hardware to schedule all needed events one by one and program timer to generate interrupt exactly in specified time. Default value depends of chosen timer capabilities, but one-shot mode is preferred, until other is forced by user or hardware. kern.eventtimer.singlemul - in periodic mode specifies how much times higher timer frequency should be, to not strictly alias hardclock() and statclock() events. Default values are 2 and 4, but could be reduced to 1 if extra interrupts are unwanted. kern.eventtimer.idletick - makes each CPU to receive every timer interrupt independently of whether they busy or not. By default this options is disabled. If chosen timer is per-CPU and runs in periodic mode, this option has no effect - all interrupts are generating. As soon as this patch modifies cpu_idle() on some platforms, I have also refactored one on x86. Now it makes use of MONITOR/MWAIT instrunctions (if supported) under high sleep/wakeup rate, as fast alternative to other methods. It allows SMP scheduler to wake up sleeping CPUs much faster without using IPI, significantly increasing performance on some highly task-switching loads. Tested by: many (on i386, amd64, sparc64 and powerc) H/W donated by: Gheorghe Ardelean Sponsored by: iXsystems, Inc.
* Fix several un-/signedness bugs of r210290 and r210293. Add one more check.mav2010-07-201-2/+3
|
* Extend timer driver API to report also minimal and maximal supported periodmav2010-07-201-11/+35
| | | | | | lengths. Make MI wrapper code to validate periods in request. Make kernel clock management code to honor these hardware limitations while choosing hz, stathz and profhz values.
* Rename timeevents.c to kern_clocksource.c.mav2010-07-141-0/+508
Suggested by: jhb@
OpenPOWER on IntegriCloud