| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
Commit the kernel changes.
Notes:
svn path=/head/; revision=217326
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
Notes:
svn path=/head/; revision=215701
|
| |
|
|
|
|
|
| |
the tree.
Notes:
svn path=/head/; revision=215317
|
| |
|
|
|
|
|
|
| |
was lauched. Few seconds event burst, accumulated during long startup,
reported to cause panic in SCHED_ULE priority calculation logic.
Notes:
svn path=/head/; revision=214987
|
| |
|
|
|
|
|
| |
to handle it.
Notes:
svn path=/head/; revision=212992
|
| |
|
|
|
|
|
|
| |
there is high probability that timer is already programmed by some other
CPU. Especially by one that registered this callout, and so active now.
Notes:
svn path=/head/; revision=212970
|
| |
|
|
|
|
|
|
|
| |
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.
Notes:
svn path=/head/; revision=212967
|
| |
|
|
|
|
|
|
|
| |
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.
Notes:
svn path=/head/; revision=212811
|
| |
|
|
|
|
|
|
|
| |
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).
Notes:
svn path=/head/; revision=212603
|
| |
|
|
|
|
|
|
|
| |
Rephrase sysctls descriptions.
Suggested by: edmaste
Notes:
svn path=/head/; revision=212600
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
Notes:
svn path=/head/; revision=212541
|
| |
|
|
| |
Notes:
svn path=/head/; revision=210298
|
| |
|
|
|
|
|
|
|
| |
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.
Notes:
svn path=/head/; revision=210290
|
|
|
Suggested by: jhb@
Notes:
svn path=/head/; revision=210069
|
