Re: kernel: return from interrupt
From: Anurekh Saxena (anurekh_at_gmail.com)
Date: 11/12/04
- Previous message: FreeBSD Tinderbox: "[current tinderbox] failure on amd64/amd64"
- In reply to: Robert Watson: "Re: kernel: return from interrupt"
- Next in thread: John Baldwin: "Re: kernel: return from interrupt"
- Reply: John Baldwin: "Re: kernel: return from interrupt"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 11 Nov 2004 22:59:54 -0500 To: Robert Watson <rwatson@freebsd.org>
> > > 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
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
- Previous message: FreeBSD Tinderbox: "[current tinderbox] failure on amd64/amd64"
- In reply to: Robert Watson: "Re: kernel: return from interrupt"
- Next in thread: John Baldwin: "Re: kernel: return from interrupt"
- Reply: John Baldwin: "Re: kernel: return from interrupt"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
