#
272461 |
|
02-Oct-2014 |
gjb |
Copy stable/10@r272459 to releng/10.1 as part of the 10.1-RELEASE process.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation |
#
256281 |
|
10-Oct-2013 |
gjb |
Copy head (r256279) to stable/10 as part of the 10.0-RELEASE cycle.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation
|
#
247463 |
|
28-Feb-2013 |
mav |
MFcalloutng: 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.
|
#
245850 |
|
23-Jan-2013 |
marius |
Revert the part of r239864 which removed obtaining the SMP mutex around reading registers from other CPUs. As it turns out, the hardware doesn't really like concurrent IPI'ing causing adverse effects. Also the thought deadlock when using this spin lock here and the targeted CPU(s) are also holding or in case of nested locks can't actually happen. This is due to the fact that on sparc64, spinlock_enter() only raises the PIL but doesn't disable interrupts completely. Thus direct cross calls as used for the register reading (and all other MD IPI needs) still will be executed by the targeted CPU(s) in that case.
MFC after: 3 days
|
#
241734 |
|
19-Oct-2012 |
marius |
Let SCHED_ULE give affinity to the CPU the tick interrupt triggered on when running tick_process(), similarly to what the x86 equivalents of this function do, however employing the less racy sequence also used in intr_event_handle().
MFC after: 3 days
|
#
239864 |
|
29-Aug-2012 |
marius |
- Unlike cache invalidation and TLB demapping IPIs, reading registers from other CPUs doesn't require locking so get rid of it. As the latter is used for the timecounter on certain machine models, using a spin lock in this case can lead to a deadlock with the upcoming callout(9) rework. - Merge r134227/r167250 from x86: Avoid cross-IPI SMP deadlock by using the smp_ipi_mtx spin lock not only for smp_rendezvous_cpus() but also for the MD cache invalidation and TLB demapping IPIs. - Mark some unused function arguments as such.
MFC after: 1 week
|
#
227309 |
|
07-Nov-2011 |
ed |
Mark all SYSCTL_NODEs static that have no corresponding SYSCTL_DECLs.
The SYSCTL_NODE macro defines a list that stores all child-elements of that node. If there's no SYSCTL_DECL macro anywhere else, there's no reason why it shouldn't be static.
|
#
223962 |
|
12-Jul-2011 |
marius |
Remove NULL assignments which are redundant for static timecounters.
Submitted by: jkim
|
#
219782 |
|
19-Mar-2011 |
marius |
On Serengeti-class machines the OFW root isn't the parent of the CPU nodes.
|
#
216628 |
|
21-Dec-2010 |
marius |
Extend the hack of r182730 to trick GAS/GCC into compiling access to STICK/STICK_COMPARE independently of the selected instruction set by TICK_COMPARE so tick.c as of r214358 once again can be compiled with gcc -mcpu=v9 for reference purposes.
|
#
214358 |
|
25-Oct-2010 |
marius |
- Given that in one-shot mode tick_et_start() also is called frequently introduce function pointers once set up to the respective implementation for reading the (S)TICK and writing the (S)STICK_COMPARE registers as a compromise between duplicating code and selecting between different implementations during execution over and over again, similar to what is done elsewhere in the MD in order to support different CPU models that won't ever change at runtime. - In the remaining tick interrupt handler further push down disabling of interrupts to the periodic case as it isn't necessary here in one-shot mode at all.
|
#
214071 |
|
19-Oct-2010 |
marius |
- Wrap exchanging td_intr_frame and calling the event timer callback in a critical section as apparently required by both. I don't think either belongs in the event timer front-ends but the callback should handle this as necessary instead just like for example intr_event_handle() does but this is how the other architectures currently handle it, either explicitly or implicitly. - Further rename and reword references to hardclock as this front-end no longer has a notion of actually calling it.
|
#
213985 |
|
17-Oct-2010 |
marius |
- In oneshot-mode it doesn't make sense to try to compensate the clock drift in order to achieve a more stable clock as the tick intervals may vary in the first place. In fact I haven't seen this code kick in when in oneshot-mode so just skip it in that case. - There's no need to explicitly stop the (S)TICK counter in oneshot-mode with every tick as it just won't trigger again with the (S)TICK compare register set to a value in the past (with a wrap-around once every ~195 years of uptime at 1.5 GHz this isn't something we have to worry about in practice). - Given that we'll disable interrupts completely anyway there's no need to enter critical sections.
|
#
211071 |
|
08-Aug-2010 |
marius |
- As it is not possible for sched_bind(9) to context switch with td_critnest > 1 when not already running on the desired CPU read the TICK counter of the BSP via a direct cross trap request in that case instead. - Treat the STICK based timecounter the same way as the TICK based one regarding its quality and obtaining the counter value from the BSP. Like the TICK timers the STICK ones also are only synchronized during their startup (which might not result in good synchronicity in the first place) but not afterwards and might drift over time, causing problems when the time is read from different CPUs (see r135972).
|
#
210601 |
|
29-Jul-2010 |
mav |
Adapt sparc64 and sun4v timer code for the new event timers infrastructure.
Reviewed by: marius@
|
#
207537 |
|
02-May-2010 |
marius |
Add support for SPARC64 V (and where it already makes sense for other HAL/Fujitsu) CPUs. For the most part this consists of fleshing out the MMU and cache handling, it doesn't add pmap optimizations possible with these CPU, yet, though. With these changes FreeBSD runs stable on Fujitsu Siemens PRIMEPOWER 250 and likely also other models based on SPARC64 V like 450, 650 and 850. Thanks go to Michael Moll for providing access to a PRIMEPOWER 250.
|
#
204152 |
|
20-Feb-2010 |
marius |
Some machines can not only consist of CPUs running at different speeds but also of different types, f.e. Sun Fire V890 can be equipped with a mix of UltraSPARC IV and IV+ CPUs, requiring different MMU initialization and different workarounds for model specific errata. Therefore move the CPU implementation number from a global variable to the per-CPU data. Functions which are called before the latter is available are passed the implementation number as a parameter now.
|
#
183201 |
|
20-Sep-2008 |
marius |
Use the STICK timers only when absolutely necessary, i.e. if a machine consists of CPUs running at different speeds, for driving hardclock as these timers in turn are driven at frequencies as low as 5MHz, resulting in bad granularity compared to the TICK timers. However, don't employ the workaround for the BlackBird erratum #1 when using the TICK timer on machines with cheetah-class CPUs for performance reasons.
Reported by: Florian Smeets
|
#
182730 |
|
03-Sep-2008 |
marius |
- USIII-based machines can consist of CPUs running at different frequencies (and having different cache sizes) so use the STICK (System TICK) timer, which was introduced due to this and is driven by the same frequency across all CPUs, instead of the TICK timer, whose frequency varies with the CPU clock, to drive hardclock. We try to use the STICK counter with all CPUs that are USIII or beyond, even when not necessary due to identical CPUs, as we can can also avoid the workaround for the BlackBird erratum #1 there. Unfortunately, using the STICK counter currently causes a hang with USIIIi MP machines for reasons unknown, so we still use the TICK timer there (which is okay as they can only consist of identical CPUs). - Given that we only (try to) synchronize the (S)TICK timers of APs with the BSP during startup, we could end up spinning forever in DELAY(9) if that function is migrated to another CPU while we're spinning due to clock drift afterwards, so pin to the CPU in order to avoid migration. Unfortunately, pinning doesn't work at the point DELAY(9) is required by the low-level console drivers, yet, so switch to a function pointer, which is updated accordingly, for implementing DELAY(9). For USIII and beyond, this would also allow to easily use the STICK counter instead of the TICK one here, there's no benefit in doing so however. While at it, use cpu_spinwait(9) for spinning in the delay- functions. This currently is a NOP though. - Don't set the TICK timer of the BSP to 0 during at startup as there's no need to do so. - Implement cpu_est_clockrate(). - Unfortunately, USIIIi-based machines don't provide a timecounter device besides the STICK and TICK counters (well, in theory the Tomatillo bridges have a performance counter that can be (ab)used as timecounter by configuring it to count bus cycles, though unlike the performance counter of Schizo bridges, the Tomatillo one is broken and counts Sun knows what in this mode). This means that we've to use a (S)TICK counter for timecounting, which has the old problem of not being in sync across CPUs, so provide an additional timecounter function which binds itself to the BSP but has an adequate low priority.
|
#
181701 |
|
13-Aug-2008 |
marius |
cosmetic changes and style fixes
|
#
172066 |
|
06-Sep-2007 |
marius |
o Revamp the sparc64 interrupt code in order to be able to interface with the INTR_FILTER-enabled MI code. Basically this consists of registering an interrupt controller (of which there can be multiple and optionally different ones either per host-to-foo bridge or shared amongst host-to-foo bridges in any one machine) along with an interrupt vector as specific argument for all the interrupt vectors used by a given host-to-foo bridge (roughly similar to registering interrupt sources on amd64 and i386), providing functions to enable, clear and disable the interrupts of the children beneath the bridge. This also includes: - No longer entering a critical section in tl0_intr() and tl1_intr() for executing interrupt handlers but rather let the handlers enter it themselves so in the case of intr_event_handle() we don't enter a nested critical section. - Adding infrastructure for binding delivery of interrupt vectors to specific CPUs which later on can be interfaced with the code from amd64/i386 for binding interrupts to specific CPUs. - Getting rid of the wrapper hack introduced along the lines of the API changes for INTR_FILTER which as a side-effect caused interrupts associated with ithread handlers only to get the elevated priority of those associated with filters ("fast handlers") (this removes the hack also in the non-INTR_FILTER case). - Disabling (by not clearing) an interrupt in the interrupt controller until all associated handlers have been executed, which is crucial for the typical locking strategy of NIC drivers in order to work correctly in case of shared interrupts. This was a more or less theoretical problem on sparc64 though, as shared interrupts are rather uncommon there except for the on-board SCCs and UARTs. Note that due to the behavior of at least of some of the interrupt controllers used on sparc64 an enable+EOI instead of a disable+EOI approach (as implied by the INTR_FILTER MI code and implemented on other architectures) is used as the latter can cause lost interrupts or in the worst case interrupt starvation. o Correct a typo in sbus_alloc_resource() which caused (pass-through) allocations to only work down to the grandchildren of the bus, which wasn't a real problem so far as we don't support any devices which are great-grandchildren or greater of a U2S bridge, yet. o In fhc(4) use bus_{read,write}_4() instead of bus_space_{read,write}_4() in order to get rid of sc_bh and sc_bt in the fhc_softc. Also get rid of some other unneeded members in fhc_softc.
Reviewed by: marcel (earlier version) Approved by: re (kensmith)
|
#
157226 |
|
28-Mar-2006 |
marius |
- Move the check for too high HZ values from tick_init() to tick_start() as we have to call tick_init() before cninit() in order to provide the low-level console drivers with a working DELAY() which in turn means we cannot use panic() in tick_init(). - s,to high, too high, in the panic string
Inspired by: kmacy's sun4v changes MFC after: 3 days
|
#
155534 |
|
11-Feb-2006 |
phk |
CPU time accounting speedup (step 2)
Keep accounting time (in per-cpu) cputicks and the statistics counts in the thread and summarize into struct proc when at context switch.
Don't reach across CPUs in calcru().
Add code to calibrate the top speed of cpu_tickrate() for variable cpu_tick hardware (like TSC on power managed machines).
Don't enforce monotonicity (at least for now) in calcru. While the calibrated cpu_tickrate ramps up it may not be true.
Use 27MHz counter on i386/Geode.
Use TSC on amd64 & i386 if present.
Use tick counter on sparc64
|
#
155444 |
|
07-Feb-2006 |
phk |
Modify the way we account for CPU time spent (step 1)
Keep track of time spent by the cpu in various contexts in units of "cputicks" and scale to real-world microsec^H^H^H^H^H^H^H^Hclock_t only when somebody wants to inspect the numbers.
For now "cputicks" are still derived from the current timecounter and therefore things should by definition remain sensible also on SMP machines. (The main reason for this first milestone commit is to verify that hypothesis.)
On slower machines, the avoided multiplications to normalize timestams at every context switch, comes out as a 5-7% better score on the unixbench/context1 microbenchmark. On more modern hardware no change in performance is seen.
|
#
153666 |
|
22-Dec-2005 |
jhb |
Tweak how the MD code calls the fooclock() methods some. Instead of passing a pointer to an opaque clockframe structure and requiring the MD code to supply CLKF_FOO() macros to extract needed values out of the opaque structure, just pass the needed values directly. In practice this means passing the pair (usermode, pc) to hardclock() and profclock() and passing the boolean (usermode) to hardclock_cpu() and hardclock_process(). Other details: - Axe clockframe and CLKF_FOO() macros on all architectures. Basically, all the archs were taking a trapframe and converting it into a clockframe one way or another. Now they can just extract the PC and usermode values directly out of the trapframe and pass it to fooclock(). - Renamed hardclock_process() to hardclock_cpu() as the latter is more accurate. - On Alpha, we now run profclock() at hz (profhz == hz) rather than at the slower stathz. - On Alpha, for the TurboLaser machines that don't have an 8254 timecounter, call hardclock() directly. This removes an extra conditional check from every clock interrupt on Alpha on the BSP. There is probably room for even further pruning here by changing Alpha to use the simplified timecounter we use on x86 with the lapic timer since we don't get interrupts from the 8254 on Alpha anyway. - On x86, clkintr() shouldn't ever be called now unless using_lapic_timer is false, so add a KASSERT() to that affect and remove a condition to slightly optimize the non-lapic case. - Change prototypeof arm_handler_execute() so that it's first arg is a trapframe pointer rather than a void pointer for clarity. - Use KCOUNT macro in profclock() to lookup the kernel profiling bucket.
Tested on: alpha, amd64, arm, i386, ia64, sparc64 Reviewed by: bde (mostly)
|
#
148823 |
|
07-Aug-2005 |
marius |
The system tick _compare_ register of USIII CPUs and up is ASR25, not ASR24 (which is the system tick register).
|
#
145150 |
|
16-Apr-2005 |
marius |
- Add a workaround for a bug in BlackBird CPUs (said to be part of the SpitFire erratum #54) which can cause writes to the TICK_CMPR register to fail. This seems to fix the dying clocks problem reported by jhb@ and kris@. [1] - In tick_start() don't reset the tick counter of the boot processor to zero. It's initially reset in _start() and afterwards but _before_ tick_start() is called on the BSP the APs synchronise with the tick counter of the BSP in mp_startup(). Resetting the tick counter of the BSP in tick_start() probably also was the cause of problems seen when using the CPU tick counter as timecounter on SMP machines. Not resetting the tick counter of the BSP in mp_startup() makes the tick counters and tick interrupts between the BSP and APs be pretty much in sync as it's supposed to be. This also means there's no longer a real reason to have separate tick_start() and tick_start_ap() so merge them and zap tick_start_ap(). This is also a first step in simplifying the interface to the tick counters in preparation to use alternate clock hardware where available. - Switch to the algorithm used on FreeBSD/ia64 for updating the tick interrupt register and which compensates the clock drift caused by varying delays between when the tick interrupts actually trigger and when they are serviced. Not compensating the clock drift mainly hurts interactive performance especially when using WITNESS. [2] For further information about the algorithm also see the commit log of sys/ia64/ia64/interrupt.c rev. 1.38. On sparc64 the sysctls for monitoring the behaviour of the tick interrupts are machdep.tick.adjust_edges, machdep.tick.adjust_excess, machdep.tick.adjust_missed and machdep.tick.adjust_ticks. - In tick_init() just use tick_stop() for stopping the tick interrupts until a proper handler is set up later. This also stops the system tick interrupt on USIII systems earlier. - In tick_start() check for a rough upper limit of HZ. - Some minor changes, e.g. use FBSDID, remove unused headers, etc.
Info obtained from: Linux [1] Ok'ed by: marcel [2] Additional testing by: kris (earlier version of the workaround), jhb X-MFC after: 3 days [1]
|
#
142001 |
|
16-Feb-2005 |
marius |
UltraSparc II[e,i] based systems come up with the tick compare register loaded, the tick interrupt enabled and a handler that resets the tick counter on every tick interrupt. While this isn't documented this can cause DELAY() to wait for a value the tick counter will not reach when used in early boot, i.e. before cpu_initclocks() is called, depending on when in the cycle DELAY() is called, the delay value and the value the tick compare register is set to. The excessive use of DELAY() in uart(4) when probing Sun keyboards seems to always manage to trigger this, resulting in a hang during boot. Disable the tick interrupt in tick_init(), which is called early in sparc64_init(), until the interrupt is enabled again in tick_start(), called by cpu_initclocks(), with our own handler. This fixes the hang during probing Sun keyboards on AXi boards and Ultra 10, with other machines like Ultra 5 probably being affected but not tested.
Additional testing by: Matthias Muthmann MFC after: 1 week
|
#
119291 |
|
22-Aug-2003 |
imp |
Prefer new location of pci include files (which have only been in the tree for two or more years now), except in a few places where there's code to be compatible with older versions of FreeBSD.
|
#
115382 |
|
29-May-2003 |
tmm |
Completely disable interrupts (not just raise %pil) when calculating the value to be written into tick_compare in tick_hardclock(). While we were taking care that the value to be written was at least TICK_GRACE ticks in the future, a vector interrupt could happen between calculating the value and writing it. If it took longer than TICK_GRACE to complete (which is doubtful for a single device-triggered vector interrupt, but quite likely for some IPIs), the value written would be in the past and tick interrupts (which drive hardclock and statclock) would stop until %tick wraps around, which takes a long time. Also, increase TICK_GRACE from 1000 to 10000 for good measure.
Reported by: kris Reviewed by: jake Approved by: re (scottl)
|
#
112398 |
|
19-Mar-2003 |
jake |
- Set cpu_impl early in sparc64_init so that we can use it to detect UltraSPARC III and higher cpus and do needed setup. - Disable the "system tick" interrupt for UltraSPARC III. This avoids an interrupt storm on startup since we're not prepared for these at all. This feature has questionable use anyway. - Clear tick on startup and then leave it alone.
|
#
110296 |
|
03-Feb-2003 |
jake |
Split statclock into statclock and profclock, and made the method for driving statclock based on profhz when profiling is enabled MD, since most platforms don't use this anyway. This removes the need for statclock_process, whose only purpose was to subdivide profhz, and gets the profiling clock running outside of sched_lock on platforms that implement suswintr. Also changed the interface for starting and stopping the profiling clock to do just that, instead of changing the rate of statclock, since they can now be separate.
Reviewed by: jhb, tmm Tested on: i386, sparc64
|
#
110190 |
|
01-Feb-2003 |
julian |
Reversion of commit by Davidxu plus fixes since applied.
I'm not convinced there is anything major wrong with the patch but them's the rules..
I am using my "David's mentor" hat to revert this as he's offline for a while.
|
#
109910 |
|
26-Jan-2003 |
jake |
Fix standard kse breakage of non-x86 platforms.
Pointy hat to: davidxu
|
#
105946 |
|
25-Oct-2002 |
tmm |
Initialize tick_MHz and related variables much earlier. After the last revision of tick.c, this was done at SI_SUB_CLOCKS, which is too late because tick_MHz is required for DELAY() to work.
Reviewed by: jake
|
#
105819 |
|
23-Oct-2002 |
jhb |
We always need sys/pcpu.h now, not just for the SMP case.
Approved by: jake
|
#
105678 |
|
22-Oct-2002 |
jake |
Start tick at the correct time (cpu_init_clocks), instead of cpu_startup.
|
#
92202 |
|
13-Mar-2002 |
jake |
Add support for driving the clocks on secondary cpus.
Submitted by: tmm
|
#
88436 |
|
23-Dec-2001 |
jake |
- Add a file for machine dependant loader metdata types. Include this in machdep.c. - Adapt to critical_* changes.
|
#
86528 |
|
18-Nov-2001 |
jake |
Avoid missing ticks and hardclock stopping.
Submitted by: tmm
|
#
84845 |
|
12-Oct-2001 |
tmm |
Implement DELAY() using the %tick register.
|
#
81391 |
|
10-Aug-2001 |
jake |
Add code to program the tick register and to setup its interrupt handler.
|