FreeBSD source tree https://cgit-dev.freebsd.org/src-test2/atom?h=release%2F6.4.0_cvs 2008-11-26T01:09:48Z 2008-11-26T01:09:48Z Ken Smith kensmith@FreeBSD.org 2008-11-26T01:09:48Z urn:sha1:a93332491e10c1a23a9fd2f11ccbdba33d72d850 Approved by: re (implicit) This commit was manufactured to restore the state of the 6.4-RELEASE image. 2005-01-05T20:05:52Z Warner Losh imp@FreeBSD.org 2005-01-05T20:05:52Z urn:sha1:f44fc746fb98516d63b1c2010f72013c8b3abb55 2004-11-20T02:29:50Z David Schultz das@FreeBSD.org 2004-11-20T02:29:50Z urn:sha1:ab44ebf5377f5c9f707cffe653f7368c7ada2d7a Reviewed by: arch@ 2004-09-02T18:59:15Z Scott Long scottl@FreeBSD.org 2004-09-02T18:59:15Z urn:sha1:9923b511ed09f7e9aff331c1de463c09bf9af55e FULL_PREEMPTION is defined. Add a runtime warning to ULE if PREEMPTION is enabled (code inspired by the PREEMPTION warning in kern_switch.c). This is a possible MT5 candidate. 2004-08-01T14:31:45Z Scott Long scottl@FreeBSD.org 2004-08-01T14:31:45Z urn:sha1:9352fe30a03aad0c103c302ed6310291f9375ca6 4 weeks of problems including deadlocks and instant panics. Note that the real bugs are likely in the scheduler. 2004-07-02T20:21:44Z John Baldwin jhb@FreeBSD.org 2004-07-02T20:21:44Z urn:sha1:0c0b25ae91328c6b388ef5faa77ec9089f2950a7 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) 2004-04-05T21:00:51Z Warner Losh imp@FreeBSD.org 2004-04-05T21:00:51Z urn:sha1:3501fd399eafa15c6b6a2fd6e565c17efb4086d2 Approved by: core 2003-07-31T01:31:32Z Peter Wemm peter@FreeBSD.org 2003-07-31T01:31:32Z urn:sha1:ad7a226f9dffc7d299010f30e139c19fc283b28c 2003-06-14T23:23:55Z Alan Cox alc@FreeBSD.org 2003-06-14T23:23:55Z urn:sha1:49a2507bd1c2d72eef3d9c9d12c9d0aeef9f3f7b to the machine-independent parts of the VM. At the same time, this introduces vm object locking for the non-i386 platforms. Two details: 1. KSTACK_GUARD has been removed in favor of KSTACK_GUARD_PAGES. The different machine-dependent implementations used various combinations of KSTACK_GUARD and KSTACK_GUARD_PAGES. To disable guard page, set KSTACK_GUARD_PAGES to 0. 2. Remove the (unnecessary) clearing of PG_ZERO in vm_thread_new. In 5.x, (but not 4.x,) PG_ZERO can only be set if VM_ALLOC_ZERO is passed to vm_page_alloc() or vm_page_grab(). 2003-03-29T18:22:29Z Andrew Gallatin gallatin@FreeBSD.org 2003-03-29T18:22:29Z urn:sha1:62f456b3159e00bb92fe7f341f151d6177e87f1f a struct pmap be the same on both SMP and UP kernels. It turns out that the size of a struct pmap is much larger on alpha SMP systems due to the number of pm_asn's being dependant on MAX_CPU. Since modules are supposed to be SMP agnostic, this has the affect of moving around the "interesting bits" of the vmspace (daddr, dsize) that the osf1 module wants to frob. So the module ends up scribbling in a pmap struct, and the user either sees a panic, or an application failure. While here, I've also shrunk MAXCPU to 8 now that it affects the size of pmap structs on UP systesm. This should be plenty, as I'm unware of any hardware we currently run in which supports more than 8 CPUs.