Date: Fri, 01 Oct 2004 11:27:08 -0400 From: Stephan Uphoff <ups@tree.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: sched_switch (sched_4bsd) may be preempted Message-ID: <1096644427.25800.26.camel@palm.tree.com> In-Reply-To: <200410010757.i917vjac017409@apollo.backplane.com> References: <1096610130.21577.219.camel@palm.tree.com> <200410010757.i917vjac017409@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 2004-10-01 at 03:57, Matthew Dillon wrote: > I would put the entire scheduler core in a critical section, not just > the part you think needs to be there. It's just too critical a subsystem > to be able to make operational assumptions of that nature in. It is > what I do in the DragonFly LWKT core, BTW, and crazy as I am I would > never even consider trying to move the critical section further in. The core is wrapped in the sched_lock. And since it is a spin lock it is running in a critical section with interrupts disabled. The additional (recursive) critical_enter is just an abusive way to tell maybe_preempt* that it should not immediately switch. ( Yes - eventually there should be a better way to do this) > > I would not reset TDP_OWEPREEMPT there. If I understand its function > correctly you need to leave it intact in order to detect preemption > request races against the scheduler. Since at that point newtd may > be non-NULL and thus not cause another scheduling queue check to be > made before the next switch, you cannot safely clear the flag where you > are clearing it. This is all running in critical section and we just decided to switch and either have or will pick the best thread. Interrupts are locked. The additional critical section just prevents recursion problems by delaying unwanted switches in maybe_preempt* . Resetting TDP_OWEPREEMPT is perfectly save since we switch to the thread chosen while everything has been locked. Stephan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1096644427.25800.26.camel>