Date: Thu, 11 Nov 2004 22:59:54 -0500 From: Anurekh Saxena <anurekh@gmail.com> To: Robert Watson <rwatson@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: kernel: return from interrupt Message-ID: <aa26c8a9041111195919bd28c@mail.gmail.com> In-Reply-To: <Pine.NEB.3.96L.1041111221149.6545E-100000@fledge.watson.org> References: <aa26c8a904111114087d4415a7@mail.gmail.com> <Pine.NEB.3.96L.1041111221149.6545E-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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. -Anurekh
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?aa26c8a9041111195919bd28c>