preemptive kernel

[Konstantin Belousov]

On Mon, May 27, 2013 at 05:00:13AM +0000, Orit Moskovich wrote:
> Just to be more specific - On x86, during a filter routine all interrupts are disabled on the cpu currently handling a filter routine or only interrupts on the IRQ that generated the interrupt? 

The CPU enters the handler through the interrupt gate, which clears the
PSL_I.  Interrupts are not re-enabled until the handler return.

> Is it possible that on a different cpu an interrupt (filter or ithread) of the same IRQ will run? Should worry about locking data because an ithread can preempt the same ithread or they'll run concurrently on different cpus?

The APIC or PCI MSI registers are programmed in the physical destination
mode.  This, together with the fact that interrupts are disabled on the
target CPU, prevents parallel or nested execution of the filter.

Having both filter and ithread for the same interrupt is apparently possible
but weird.  I do not see anything which would prevent interrupt filter
from being executed while the ithread is running.  But again, this is
very unusual setup.

ithread has single stack, it cannot be run simultaneously on several CPUs.

> 
> -----Original Message-----
> From: Konstantin Belousov [mailto:kostikbel at gmail.com] 
> Sent: Sunday, May 26, 2013 06:48 PM
> To: Orit Moskovich
> Cc: freebsd-hackers at freebsd.org
> Subject: Re: preemptive kernel
> 
> On Sun, May 26, 2013 at 11:09:03AM +0000, Orit Moskovich wrote:
> > Can a filter routine preempt another filter routine? And can an interrupt thread (or a filter routine) preempt another ithread?
> 
> Filter handler borrows the context from the thread executed at the time of the interrupt.  At least on x86 (i.e. i386 and amd64) interrupt handlers are executed with the interrupts disabled.  So the filter cannot interrupt another filter.
> 
> Interrupt threads are executed with the interrupts enabled. So if an interrupt is delivered to the CPU while the CPU executed the ithread, the filter 'preempts' the ithread by executing in its context.  For the same reason, if the interrupt delivered causes a higher-priority thread become ready to run, then the new runnable thread could preempt the interrupt thread according to the priority, affinity and other factors considered by a scheduler.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20130527/e4bddc63/attachment.sig>