#
331722 |
|
29-Mar-2018 |
eadler |
Revert r330897:
This was intended to be a non-functional change. It wasn't. The commit message was thus wrong. In addition it broke arm, and merged crypto related code.
Revert with prejudice.
This revert skips files touched in r316370 since that commit was since MFCed. This revert also skips files that require $FreeBSD$ property changes.
Thank you to those who helped me get out of this mess including but not limited to gonzo, kevans, rgrimes.
Requested by: gjb (re)
|
#
331017 |
|
15-Mar-2018 |
kevans |
MFC r317055,r317056 (glebius): Include sys/vmmeter.h as included
r317055: All these files need sys/vmmeter.h, but now they got it implicitly included via sys/pcpu.h.
r317056: Typo!
|
#
330897 |
|
14-Mar-2018 |
eadler |
Partial merge of the SPDX changes
These changes are incomplete but are making it difficult to determine what other changes can/should be merged.
No objections from: pfg
|
#
302408 |
|
07-Jul-2016 |
gjb |
Copy head@r302406 to stable/11 as part of the 11.0-RELEASE cycle. Prune svn:mergeinfo from the new branch, as nothing has been merged here.
Additional commits post-branch will follow.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation |
#
299070 |
|
04-May-2016 |
pfg |
sys/sparc64: minor spelling fixes.
Only affects comments: no functional change.
|
#
271712 |
|
17-Sep-2014 |
adrian |
Migrate ie->ie_assign_cpu and associated code to use an int for CPU rather than u_char.
Migrate post_filter to use an int for a CPU rather than u_char.
Change intr_event_bind() to use an int for CPU rather than u_char.
It touches the ppc, sparc64, arm and mips machdep code but it should (hah!) be a no-op.
Tested:
* i386, AMD64 laptops
Reviewed by: jhb
|
#
241780 |
|
20-Oct-2012 |
marius |
- Give PIL_PREEMPT the lowest priority just above low/stray interrupts. The reason for this is that the SPARC v9 architecture allows nested interrupts of higher priority/level than that of the current interrupt to occur (and we can't just entirely bypass this model, also, at least for tick interrupts, this also wouldn't be wise). However, when a preemption interrupt interrupts another interrupt of lower priority, f.e. PIL_ITHREAD, and that one in turn is nested by a third interrupt, f.e. PIL_TICK, with SCHED_ULE the execution of interrupts higher than PIL_PREEMPT may be migrated to another CPU. In particular, tl1_ret(), which is responsible for restoring the state of the CPU prior to entry to the interrupt based on the (also migrated) trap frame, then is run on a CPU which actually didn't receive the interrupt in question, causing an inappropriate processor interrupt level to be "restored". In turn, this causes interrupts of the first level, i.e. PIL_ITHREAD in the above scenario, to be blocked on the target of the migration until the correct PIL happens to be restored again on that CPU again. Making PIL_PREEMPT the lowest real priority, this effectively prevents this scenario from happening, as preemption interrupts no longer can interrupt any other interrupt besides stray ones (which is no issue). Thanks to attilio@ and especially mav@ for helping me to understand this problem at the 201208DevSummit. - Give PIL_STOP (which is also used for IPI_STOP_HARD, given that there's no real equivalent to NMIs on SPARC v9) the highest possible priority just below the hardwired PIL_TICK, so it has a chance to interrupt more things.
MFC after: 1 week
|
#
241371 |
|
09-Oct-2012 |
attilio |
Reverts r234074,234105,234564,234723,234989,235231-235232 and part of r234247. Use, instead, the static intializer introduced in r239923 for x86 and sparc64 intr_cpus, unwinding the code to the initial version.
Reviewed by: marius
|
#
235231 |
|
10-May-2012 |
marius |
Merge r234989 from x86:
Revert part of r234723 by re-enabling the SMP protection for intr_bind().
|
#
234723 |
|
26-Apr-2012 |
attilio |
Clean up the intr* MD KPI from the SMP dependency, removing a cause of discrepancy between modules and kernel, but deal with SMP differences within the functions themselves.
As an added bonus this also helps in terms of code readability.
Requested by: gibbs Reviewed by: jhb, marius MFC after: 1 week
|
#
234247 |
|
13-Apr-2012 |
marius |
Merge from x86:
r233961:
Fix interrupt load balancing regression, introduced in revision 222813, that left all un-pinned interrupts assigned to CPU 0. In intr_shuffle_irqs(), remove CPU_SETOF() call that initialized the "intr_cpus" cpuset to only contain CPU0.
This initialization is too late and nullifies the results of calls to the intr_add_cpu() that occur much earlier in the boot process.
r234074 (partial):
The BSP is not added to the mask of valid target CPUs for interrupts. Fix this by adding the BSP as an interrupt target directly in
r234105:
Fix !SMP build after r234074.
MFC after: 3 days
|
#
224187 |
|
18-Jul-2011 |
attilio |
- Remove the eintrcnt/eintrnames usage and introduce the concept of sintrcnt/sintrnames which are symbols containing the size of the 2 tables. - For amd64/i386 remove the storage of intr* stuff from assembly files. This area can be widely improved by applying the same to other architectures and likely finding an unified approach among them and move the whole code to be MI. More work in this area is expected to happen fairly soon.
No MFC is previewed for this patch.
Tested by: pluknet Reviewed by: jhb Approved by: re (kib)
|
#
223235 |
|
18-Jun-2011 |
marius |
- As with stray vector interrupts limit the reporting of stray level interrupts. Bringup on additional machine models repeatedly reveals firmware that enables interrupts behind our back, causing the console to be flooded otherwise. - As with the regular interrupt counters using uint16_t instead of u_long for counting the stray vector interrupts should be more than sufficient. - Cache the interrupt vector in intr_stray_vector().
|
#
222813 |
|
07-Jun-2011 |
attilio |
etire the cpumask_t type and replace it with cpuset_t usage.
This is intended to fix the bug where cpu mask objects are capped to 32. MAXCPU, then, can now arbitrarely bumped to whatever value. Anyway, as long as several structures in the kernel are statically allocated and sized as MAXCPU, it is suggested to keep it as low as possible for the time being.
Technical notes on this commit itself: - More functions to handle with cpuset_t objects are introduced. The most notable are cpusetobj_ffs() (which calculates a ffs(3) for a cpuset_t object), cpusetobj_strprint() (which prepares a string representing a cpuset_t object) and cpusetobj_strscan() (which creates a valid cpuset_t starting from a string representation). - pc_cpumask and pc_other_cpus are target to be removed soon. With the moving from cpumask_t to cpuset_t they are now inefficient and not really useful. Anyway, for the time being, please note that access to pcpu datas is protected by sched_pin() in order to avoid migrating the CPU while reading more than one (possible) word - Please note that size of cpuset_t objects may differ between kernel and userland. While this is not directly related to the patch itself, it is good to understand that concept and possibly use the patch as a reference on how to deal with cpuset_t objects in userland, when accessing kernland members. - KTR_CPUMASK is changed and now is represented through a string, to be set as the example reported in NOTES.
Please additively note that no MAXCPU is bumped in this patch, but private testing has been done until to MAXCPU=128 on a real 8x8x2(htt) machine (amd64).
Please note that the FreeBSD version is not yet bumped because of the upcoming pcpu changes. However, note that this patch is not targeted for MFC.
People to thank for the time spent on this patch: - sbruno, pluknet and Nicholas Esborn (nick AT desert DOT net) tested several revision of the patches and really helped in improving stability of this work. - marius fixed several bugs in the sparc64 implementation and reviewed patches related to ktr. - jeff and jhb discussed the basic approach followed. - kib and marcel made targeted review on some specific part of the patch. - marius, art, nwhitehorn and andreast reviewed MD specific part of the patch. - marius, andreast, gonzo, nwhitehorn and jceel tested MD specific implementations of the patch. - Other people have made contributions on other patches that have been already committed and have been listed separately.
Companies that should be mentioned for having participated at several degrees: - Yahoo! for having offered the machines used for testing on big count of CPUs. - The FreeBSD Foundation for having sponsored my devsummit attendance, which has been instrumental. - Sandvine for having offered offices and infrastructure during development.
(I really hope I didn't forget anyone, if it happened I apologize in advance).
|
#
216961 |
|
04-Jan-2011 |
marius |
Reserve INTR_MD[1-4] similarly to what BUS_DMA_BUS[1-4] are intended for and switch sparc64 to use the first one for bus error filter handlers of bridge drivers instead of (ab)using INTR_FAST for that so we eventually can get rid of the latter.
Reviewed by: jhb MFC after: 1 month
|
#
212541 |
|
13-Sep-2010 |
mav |
Refactor timer management code with priority to one-shot operation mode. 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.
|
#
210601 |
|
29-Jul-2010 |
mav |
Adapt sparc64 and sun4v timer code for the new event timers infrastructure.
Reviewed by: marius@
|
#
200948 |
|
24-Dec-2009 |
marius |
Merge from amd64/i386: Implement support for interrupt descriptions.
|
#
200947 |
|
24-Dec-2009 |
marius |
Add missing locking in intr_bind().
|
#
200938 |
|
24-Dec-2009 |
marius |
- Don't check for a valid interrupt controller on every interrupt in intr_execute_handlers(). If we managed to get here without an associated interrupt controller we have way bigger problems. While at it predict stray vector interrupts as false as they are rather unlikely. - Don't blindly call the clear function of an interrupt controller when adding a handler in inthand_add() as interrupt controllers like the one driven by upa(4) are auto-clearing and thus provide NULL instead.
|
#
185109 |
|
19-Nov-2008 |
marius |
Use the interrupt level right below PIL_FAST for executing interrupt filters instead of PIL_FAST and allow special filters and handlers for interrupts which need to be able to interrupt even filters, f.e. bus error interrupts, to be registered with the revived INTR_FAST at PIL_FAST.
|
#
183144 |
|
18-Sep-2008 |
marius |
- Add a missing prototype. - Remove a banal comment.
|
#
178443 |
|
23-Apr-2008 |
marius |
o Rename ic_eoi to ic_clear to emphasize the functions it points don't send and EOI which works like on amd64/i386 and blocks all interrupts on the relevant interrupt controller. o Replace the post_filter and post_inthread hooks registered when creating the interrupt events with just ic_clear as on sparc64 we don't need to do any disable->EOI->enable dance to unblock all but the relevant interrupt while running the filter or handler; just not clearing the interrupt already has the same effect. o Merge from amd64/i386: - Split the intr_table_lock into an sx lock used for most things, and a spin lock to protect intrcnt_index. - Add support for binding interrupts to CPUs, including for the bus_bind_intr(9) interface, a assign_cpu hook and initially shuffling interrupts arround in a round-robin fashion.
Reviewed by: jhb MFC after: 1 month
|
#
178092 |
|
11-Apr-2008 |
jeff |
- Add the interrupt vector number to intr_event_create so MI code can lookup hard interrupt events by number. Ignore the irq# for soft intrs. - Add support to cpuset for binding hardware interrupts. This has the side effect of binding any ithread associated with the hard interrupt. As per restrictions imposed by MD code we can only bind interrupts to a single cpu presently. Interrupts can be 'unbound' by binding them to all cpus.
Reviewed by: jhb Sponsored by: Nokia
|
#
178048 |
|
09-Apr-2008 |
marius |
- Add support for IPI_PREEMPT. [1] - Add my copyright to mp_machdep.c for having implemented support for USIII and up and some fixes.
Obtained from: sun4v (modulo style(9) bugs) [1]
|
#
177940 |
|
05-Apr-2008 |
jhb |
Add a MI intr_event_handle() routine for the non-INTR_FILTER case. This allows all the INTR_FILTER #ifdef's to be removed from the MD interrupt code. - Rename the intr_event 'eoi', 'disable', and 'enable' hooks to 'post_filter', 'pre_ithread', and 'post_ithread' to be less x86-centric. Also, add a comment describe what the MI code expects them to do. - On amd64, i386, and powerpc this is effectively a NOP. - On arm, don't bother masking the interrupt unless the ithread is scheduled in the non-INTR_FILTER case to match what INTR_FILTER did. Also, don't bother unmasking the interrupt in the post_filter case if we never masked it. The INTR_FILTER case had been doing this by having arm_unmask_irq for the post_filter (formerly 'eoi') hook. - On ia64, stray interrupts are now masked for the non-INTR_FILTER case. They were already masked in the INTR_FILTER case. - On sparc64, use the a NULL pre_ithread hook and use intr_enable_eoi() for both the 'post_filter' and 'post_ithread' hooks to match what the non-INTR_FILTER code did. - On sun4v, retire the ithread wrapper hack by using an appropriate 'post_ithread' hook instead (it's what 'post_ithread'/'enable' was designed to do even in 5.x).
Glanced at by: piso Reviewed by: marius Requested by: marius [1], [5] Tested on: amd64, i386, arm, sparc64
|
#
177325 |
|
17-Mar-2008 |
jhb |
Simplify the interrupt code a bit: - Always include the ie_disable and ie_eoi methods in 'struct intr_event' and collapse down to one intr_event_create() routine. The disable and eoi hooks simply aren't used currently in the !INTR_FILTER case. - Expand 'disab' to 'disable' in a few places. - Use function casts for arm and i386:intr_eoi_src() instead of wrapper routines since to trim one extra indirection.
Compiled on: {arm,amd64,i386,ia64,ppc,sparc64} x {FILTER, !FILTER} Tested on: {amd64,i386} x {FILTER, !FILTER}
|
#
177181 |
|
14-Mar-2008 |
jhb |
Add preliminary support for binding interrupts to CPUs: - Add a new intr_event method ie_assign_cpu() that is invoked when the MI code wishes to bind an interrupt source to an individual CPU. The MD code may reject the binding with an error. If an assign_cpu function is not provided, then the kernel assumes the platform does not support binding interrupts to CPUs and fails all requests to do so. - Bind ithreads to CPUs on their next execution loop once an interrupt event is bound to a CPU. Only shared ithreads are bound. We currently leave private ithreads for drivers using filters + ithreads in the INTR_FILTER case unbound. - A new intr_event_bind() routine is used to bind an interrupt event to a CPU. - Implement binding on amd64 and i386 by way of the existing pic_assign_cpu PIC method. - For x86, provide a 'intr_bind(IRQ, cpu)' wrapper routine that looks up an interrupt source and binds its interrupt event to the specified CPU. MI code can currently (ab)use this by doing:
intr_bind(rman_get_start(irq_res), cpu);
however, I plan to add a truly MI interface (probably a bus_bind_intr(9)) where the implementation in the x86 nexus(4) driver would end up calling intr_bind() internally.
Requested by: kmacy, gallatin, jeff Tested on: {amd64, i386} x {regular, INTR_FILTER}
|
#
173799 |
|
21-Nov-2007 |
scottl |
Extend critical section coverage in the low-level interrupt handlers to include the ithread scheduling step. Without this, a preemption might occur in between the interrupt getting masked and the ithread getting scheduled. Since the interrupt handler runs in the context of curthread, the scheudler might see it as having a such a low priority on a busy system that it doesn't get to run for a _long_ time, leaving the interrupt stranded in a disabled state. The only way that the preemption can happen is by a fast/filter handler triggering a schduling event earlier in the handler, so this problem can only happen for cases where an interrupt is being shared by both a fast/filter handler and an ithread handler. Unfortunately, it seems to be common for this sharing to happen with network and USB devices, for example. This fixes many of the mysterious TCP session timeouts and NIC watchdogs that were being reported. Many thanks to Sam Lefler for getting to the bottom of this problem.
Reviewed by: jhb, jeff, silby
|
#
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)
|
#
170162 |
|
31-May-2007 |
piso |
In some particular cases (like in pccard and pccbb), the real device handler is wrapped in a couple of functions - a filter wrapper and an ithread wrapper. In this case (and just in this case), the filter wrapper could ask the system to schedule the ithread and mask the interrupt source if the wrapped handler is composed of just an ithread handler: modify the "old" interrupt code to make it support this situation, while the "new" interrupt code is already ok.
Discussed with: jhb
|
#
166901 |
|
23-Feb-2007 |
piso |
o break newbus api: add a new argument of type driver_filter_t to bus_setup_intr()
o add an int return code to all fast handlers
o retire INTR_FAST/IH_FAST
For more info: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=465712+0+current/freebsd-current
Reviewed by: many Approved by: re@
|
#
151658 |
|
25-Oct-2005 |
jhb |
Reorganize the interrupt handling code a bit to make a few things cleaner and increase flexibility to allow various different approaches to be tried in the future. - Split struct ithd up into two pieces. struct intr_event holds the list of interrupt handlers associated with interrupt sources. struct intr_thread contains the data relative to an interrupt thread. Currently we still provide a 1:1 relationship of events to threads with the exception that events only have an associated thread if there is at least one threaded interrupt handler attached to the event. This means that on x86 we no longer have 4 bazillion interrupt threads with no handlers. It also means that interrupt events with only INTR_FAST handlers no longer have an associated thread either. - Renamed struct intrhand to struct intr_handler to follow the struct intr_foo naming convention. This did require renaming the powerpc MD struct intr_handler to struct ppc_intr_handler. - INTR_FAST no longer implies INTR_EXCL on all architectures except for powerpc. This means that multiple INTR_FAST handlers can attach to the same interrupt and that INTR_FAST and non-INTR_FAST handlers can attach to the same interrupt. Sharing INTR_FAST handlers may not always be desirable, but having sio(4) and uhci(4) fight over an IRQ isn't fun either. Drivers can always still use INTR_EXCL to ask for an interrupt exclusively. The way this sharing works is that when an interrupt comes in, all the INTR_FAST handlers are executed first, and if any threaded handlers exist, the interrupt thread is scheduled afterwards. This type of layout also makes it possible to investigate using interrupt filters ala OS X where the filter determines whether or not its companion threaded handler should run. - Aside from the INTR_FAST changes above, the impact on MD interrupt code is mostly just 's/ithread/intr_event/'. - A new MI ddb command 'show intrs' walks the list of interrupt events dumping their state. It also has a '/v' verbose switch which dumps info about all of the handlers attached to each event. - We currently don't destroy an interrupt thread when the last threaded handler is removed because it would suck for things like ppbus(8)'s braindead behavior. The code is present, though, it is just under #if 0 for now. - Move the code to actually execute the threaded handlers for an interrrupt event into a separate function so that ithread_loop() becomes more readable. Previously this code was all in the middle of ithread_loop() and indented halfway across the screen. - Made struct intr_thread private to kern_intr.c and replaced td_ithd with a thread private flag TDP_ITHREAD. - In statclock, check curthread against idlethread directly rather than curthread's proc against idlethread's proc. (Not really related to intr changes)
Tested on: alpha, amd64, i386, sparc64 Tested on: arm, ia64 (older version of patch by cognet and marcel)
|
#
145153 |
|
16-Apr-2005 |
marius |
- MFi386: sys/i386/i386/intr_machdep.c rev. 1.11 Don't use atomic ops to increment interrupt stats. On sparc64 this reduces delay until tick interrupts are service by 1/10th on average. In turn this reduces the clock drift caused by these delays so there's less drift which has to be compensated in tick_hardclock(). This includes switching from atomically incrementing the global cnt.v_intr to the asm equivalent of PCPU_LAZY_INC(cnt.v_intr) in exception.S - Correct some comments to match the registers actually used. - Correct some format specifiers, interrupt levels passed in are u_int. - Use FBSDID.
Ok'ed by: jhb
|
#
145152 |
|
16-Apr-2005 |
marius |
Some changes to intr_execute_handlers(): - Fix NULL pointer dereferences caused when an ithread or a handler is NULL which happens when a stray interrupt triggers after the respective device interrupt was torn down. - Remove the critical section around INTR_FAST handlers which actually was a nested critical section. Both tl0_intr() and tl1_intr() already enter a critical section for calling intr_execute_handlers().
MFC after: 3 days
|
#
143024 |
|
02-Mar-2005 |
marius |
- Allow multiple INTR_FAST handlers for the same source. The motivation for this are the on-board SCCs and UARTs that use a shared IRQ. [1] - Rework the interrupt counting code to account for shared interrupts. [1] - In case ithread_add_handler() failed in inthand_add() just return with the error code instead of setting up a non-fast handler regardless or setting up a non-fast handler instead of a fast handler. I can't think of a situation where the former behaviour would do the right thing.
Reviewed by: marcel [1] Based on: sys/i386/i386/intr_machdep.c [1]
|
#
143021 |
|
02-Mar-2005 |
marius |
Assorted style fixes and minor changes: - Use FBSDID. - Use uintXX_t instead of u_intXX_t. - Be consistent with white-space. - Mark some globals as static. - Add a missing prototype. - Remove a unused variable. - etc.
|
#
131481 |
|
02-Jul-2004 |
jhb |
Implement preemption of kernel threads natively in the scheduler rather than as one-off hacks in various other parts of the kernel: - Add a function maybe_preempt() that is called from sched_add() to determine if a thread about to be added to a run queue should be preempted to directly. If it is not safe to preempt or if the new thread does not have a high enough priority, then the function returns false and sched_add() adds the thread to the run queue. If the thread should be preempted to but the current thread is in a nested critical section, then the flag TDF_OWEPREEMPT is set and the thread is added to the run queue. Otherwise, mi_switch() is called immediately and the thread is never added to the run queue since it is switch to directly. When exiting an outermost critical section, if TDF_OWEPREEMPT is set, then clear it and call mi_switch() to perform the deferred preemption. - Remove explicit preemption from ithread_schedule() as calling setrunqueue() now does all the correct work. This also removes the do_switch argument from ithread_schedule(). - Do not use the manual preemption code in mtx_unlock if the architecture supports native preemption. - Don't call mi_switch() in a loop during shutdown to give ithreads a chance to run if the architecture supports native preemption since the ithreads will just preempt DELAY(). - Don't call mi_switch() from the page zeroing idle thread for architectures that support native preemption as it is unnecessary. - Native preemption is enabled on the same archs that supported ithread preemption, namely alpha, i386, and amd64.
This change should largely be a NOP for the default case as committed except that we will do fewer context switches in a few cases and will avoid the run queues completely when preempting.
Approved by: scottl (with his re@ hat)
|
#
127977 |
|
07-Apr-2004 |
imp |
Remove advertising clause from University of California Regent's license, per letter dated July 22, 1999 and email from Peter Wemm, Alan Cox and Robert Watson.
Approved by: core, peter, alc, rwatson
|
#
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.
|
#
117658 |
|
15-Jul-2003 |
jmg |
add support for interrupt counting on sparc64. This copies part of the code from i386. The code has a slight bogon that interrupts are counted twice. Once on the ithread dispatch and once on the dispatch for the vector
vmstat -i and systat -vm now contains interrupt counts.
Reviewed by: jake
|
#
105733 |
|
22-Oct-2002 |
jake |
- Expand struct trapframe to 256 bytes, make all fields fixed width and the same size. Add some fields that previously overlapped with something else or were missing. - Make struct regs and struct mcontext (minus floating point) the same as struct trapframe so converting between them is easy (null). - Add space for saving floating point state to struct mcontext. This requires that it be 64 byte aligned. - Add assertions that none of these structures change size, as they are part of the ABI. - Remove some dead code in sendsig(). - Save and restore %gsr in struct trapframe. Remember to restore %fsr. - Add some comments to exception.S.
|
#
104075 |
|
28-Sep-2002 |
jake |
Renamed intr_enqueue to intr_vector and intr_dequeue to intr_fast, to better reflect how they are called.
|
#
97265 |
|
25-May-2002 |
jake |
Convert the interrupt queue from an array to a linked list. Implement intr_dequeue in asm so that it can easily be modified to do light weight context switching.
|
#
93818 |
|
04-Apr-2002 |
jhb |
Change callers of mtx_init() to pass in an appropriate lock type name. In most cases NULL is passed, but in some cases such as network driver locks (which use the MTX_NETWORK_LOCK macro) and UMA zone locks, a name is used.
Tested on: i386, alpha, sparc64
|
#
92204 |
|
13-Mar-2002 |
jake |
Use intr_disable/intr_restore instead of doing it manually.
Submitted by: tmm
|
#
90624 |
|
13-Feb-2002 |
tmm |
Avoid crashing in early boot when WITNESS is enabled by moving the mtx_init() for intr_table_lock after the globaldata pointer initialization.
|
#
89045 |
|
08-Jan-2002 |
jake |
Make this code more robust in the event of stray interrupts. Handle stray level interrupts as well.
|
#
88638 |
|
29-Dec-2001 |
jake |
intr_handlers is an array of function pointers, not small structures. Assert at compile time that structures which need to be a power of 2 in size really are.
|
#
88088 |
|
17-Dec-2001 |
jhb |
Modify the critical section API as follows: - The MD functions critical_enter/exit are renamed to start with a cpu_ prefix. - MI wrapper functions critical_enter/exit maintain a per-thread nesting count and a per-thread critical section saved state set when entering a critical section while at nesting level 0 and restored when exiting to nesting level 0. This moves the saved state out of spin mutexes so that interlocking spin mutexes works properly. - Most low-level MD code that used critical_enter/exit now use cpu_critical_enter/exit. MI code such as device drivers and spin mutexes use the MI wrappers. Note that since the MI wrappers store the state in the current thread, they do not have any return values or arguments. - mtx_intr_enable() is replaced with a constant CRITICAL_FORK which is assigned to curthread->td_savecrit during fork_exit().
Tested on: i386, alpha
|
#
87702 |
|
11-Dec-2001 |
jhb |
Overhaul the per-CPU support a bit:
- The MI portions of struct globaldata have been consolidated into a MI struct pcpu. The MD per-CPU data are specified via a macro defined in machine/pcpu.h. A macro was chosen over a struct mdpcpu so that the interface would be cleaner (PCPU_GET(my_md_field) vs. PCPU_GET(md.md_my_md_field)). - All references to globaldata are changed to pcpu instead. In a UP kernel, this data was stored as global variables which is where the original name came from. In an SMP world this data is per-CPU and ideally private to each CPU outside of the context of debuggers. This also included combining machine/globaldata.h and machine/globals.h into machine/pcpu.h. - The pointer to the thread using the FPU on i386 was renamed from npxthread to fpcurthread to be identical with other architectures. - Make the show pcpu ddb command MI with a MD callout to display MD fields. - The globaldata_register() function was renamed to pcpu_init() and now init's MI fields of a struct pcpu in addition to registering it with the internal array and list. - A pcpu_destroy() function was added to remove a struct pcpu from the internal array and list.
Tested on: alpha, i386 Reviewed by: peter, jake
|
#
86143 |
|
06-Nov-2001 |
tmm |
Fix the intial setup of the stray interrupt handler (it takes a struct *intr_vec as argument now, not the vector number).
|
#
85257 |
|
20-Oct-2001 |
jake |
Remove interrupt queue array. Its in globaldata now.
|
#
85235 |
|
20-Oct-2001 |
jake |
Change the stray count in struct intr_vector to a vector number that can be used to index tables of counters. Remove intr_dispatch() inline, it is implemented directly in tl*_intr now. Count stray interrupts in a table of counters like intrcnt. Disable interrupts briefly when setting up the interrupt vector table. We must disable interrupts completely, not just raise the pil. Pass pointers to the intr_vector structures rather than a vector number to sched_ithd and intr_stray.
|
#
84849 |
|
12-Oct-2001 |
tmm |
Add inthand_add() and inthand_remove() for use by the MD bus code and some glue code.
|
#
81390 |
|
10-Aug-2001 |
jake |
Add early code to support interrupts.
|