Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 11 Nov 2004 22:22:45 +0000 (GMT)
From:      Robert Watson <rwatson@freebsd.org>
To:        Anurekh Saxena <anurekh@gmail.com>
Cc:        freebsd-current@freebsd.org
Subject:   Re: kernel: return from interrupt
Message-ID:  <Pine.NEB.3.96L.1041111221149.6545E-100000@fledge.watson.org>
In-Reply-To: <aa26c8a904111114087d4415a7@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help

On Thu, 11 Nov 2004, 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.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert@fledge.watson.org      Principal Research Scientist, McAfee Research



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1041111221149.6545E-100000>