Date: Mon, 15 Nov 2004 17:46:03 -0500 From: Anurekh Saxena <anurekh@gmail.com> To: John Baldwin <jhb@freebsd.org> Cc: Robert Watson <rwatson@freebsd.org> Subject: Re: kernel: return from interrupt Message-ID: <aa26c8a904111514461bf8e2f3@mail.gmail.com> In-Reply-To: <200411151433.57236.jhb@FreeBSD.org> References: <aa26c8a904111114087d4415a7@mail.gmail.com> <Pine.NEB.3.96L.1041111221149.6545E-100000@fledge.watson.org> <aa26c8a9041111195919bd28c@mail.gmail.com> <200411151433.57236.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 15 Nov 2004 14:33:57 -0500, John Baldwin <jhb@freebsd.org> wrote: > On Thursday 11 November 2004 10:59 pm, Anurekh Saxena wrote: > > > > > > > Even normal "options PREEMPTION" should do this. I know from tracing > > > > > the kernel in 6.x that that's the way the system behaves out of the > > > > > box; with PREEMPTION turned on in 5.x you should see the same > > > > > behavior. One thing I often do see, FWIW, is that if you're on an > > > > > SMP box, the ithread will get scheduled to run immediately on another > > > > > CPU that's idle, so you won't actually preempt the thread on the > > > > > current CPU other than for the interrupt handler. What behavior are > > > > > you seeing that suggests this isn't happening with PREEMPTION > > > > > compiled in? > > > > > > > > I may be missing something fundamental here, but, doreti (exceptions.s) > > > > does not call 'ast' for an interrupted task, that does not have RPL of > > > > 3 (user). So, even if an interrupt is pending, and the 'NEEDRESCHED' > > > > is set, the scheduling decision is delayed till the kernel thread or > > > > whatever was running in the kernel sleeps, or give up the cpu(call > > > > mi_switch), or returns to user mode. > > > > > > > > AFAIK this is the only return path from an interrupt. Unless there is > > > > another return path for the interrupts, the scheduler is not invoked on > > > > a return. > > > > > > Assuming we're talking about i386, lapic_handle_intr() will call > > > intr_execute_handlers(), which will walk the list of handlers for the > > > interrupt, and either directly invoke the fast handlers of the > > > interrupts, or call ithread_schedule() to schedule the ithread. > > > ithread_schedule() will invoke setrunqueue(), which enters the scheduler > > > and is a preemption point. If you dig down a bit, you'll find a call to > > > maybe_preempt(), which may preempt if appropriate, resulting in a call to > > > mi_switch() to the ithread. The maybe_preempt() code will only kick in > > > to actually switch if PREEMPTION is defined. > > > > Yeah, I got it wrong. Without the FULL_PREEMPTION enabled, it does not > > preempt unless the current thread is in the idle priority band. > > I was expecting the NEEDRESCHED flag to be used for preemption on > > return paths, especially for interrupt context. I think this method > > works better since preemption points become well defined in the > > kernel. > > Thanks for helping me figure this out. > > NEEDRESCHED (albeit rather broken at the moment) is used to implement > preemptino of user threads. As Robert mentioned above, in-kernel preemption > is managed via either direct switches in setrunqueue() or deferred > preemptions via TDF_OWEPREEMPT in critical_exit(). > Yeah, I think I get the way its done, but it would be nice to be able to use the NEEDRESCHED flag as a general way to say... we need to resched, irrespective of which mode we are returning to. I don't know how much of the code expecrs the current behavior. I can think of atleast two ways in which the generic flag could be used. I don't know whether its a good idea or not. Just a thought. 1> The generic return-from-'some form of interrupt' path can simply call the scheduler if the flag is set. Though I cant think of any examples to provide, but it may be used as a defer flag, just like the TDF_OWEPREEMPT is used at the moment. 2> A kernel thread that wants to be able to do as much work as it can, may keep checking this flag and know when to preempt. Thanks, -Anurekh
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?aa26c8a904111514461bf8e2f3>