svn commit: r211176 - in head/sys: amd64/amd64 i386/i386

[Attilio Rao]

2010/8/11 Kostik Belousov <kostikbel at gmail.com>:
> On Wed, Aug 11, 2010 at 01:21:46PM +0200, Attilio Rao wrote:
>> 2010/8/11 Kostik Belousov <kostikbel at gmail.com>:
>> > On Wed, Aug 11, 2010 at 10:51:27AM +0000, Attilio Rao wrote:
>> >> Author: attilio
>> >> Date: Wed Aug 11 10:51:27 2010
>> >> New Revision: 211176
>> >> URL: http://svn.freebsd.org/changeset/base/211176
>> >>
>> >> Log:
>> >>   IPI handlers may run generally with interrupts disabled because they
>> >>   are served via an interrupt gate.
>> >>
>> >>   However, that doesn't explicitly prevent preemption and thread
>> >>   migration thus scheduler pinning may be necessary in some handlers.
>> >>   Fix that.
>> >
>> > How the preemption is supposed to happen ? Aside from the explicit
>> > calls to mi_switch() from e.g. critical_exit().
>>
>> IIRC it should be hardclock() willing to schedule the softclock(). It
>> is the critical_exit() in the thread_unlock() that may trigger it
>> (sorry for not digging more, it was a while back that I hacked this
>> part, but I guess you can verify on your own).
>> We already have other points within the kernel that take care of
>> dealing with preemption/migration like lapic_handle_timer(), for
>> example.
>
> Right, and if the interrupts are indeed disabled, I do not see how
> the preemption may be triggered in the fragments like
>        cpu = PCPU_GET(cpuid);
>        cpumask = PCPU_GET(cpumask);

I don't recall all the details and I have no time to dig now. However,
also spinlock_enter() does disable explicitly preemption via
critical_enter() after have disabled the interrupts.
Let me CC jhb as he implemented spinlock_enter() and may have a clue
about how preemption can happen with interrupts disabled.

Thanks,
Attilio


-- 
Peace can only be achieved by understanding - A. Einstein