svn commit: r222060 - in user/avg/xcpu/sys: kern sys

[Attilio Rao]

2011/5/26  <mdf at freebsd.org>:
> On Thu, May 26, 2011 at 9:05 AM, Andriy Gapon <avg at freebsd.org> wrote:
>> on 26/05/2011 18:46 mdf at FreeBSD.org said the following:
>>> A per-thread flag is needed as long as other CPUs can be running or
>>> even just the scheduler on the remaining CPU.  So I would thing that
>>> flag needs to be checked until the system has been massaged to the
>>> state you describe above.
>>
>> I am not sure that I understand your reasoning if you mean that the flag needs to
>> be checked in TD_IS_INPANIC.  That is, right now there is no TD_IS_INPANIC and
>> things work after panic to a certain degree.  I do not intend to improve that
>> degree and just want to keep an option to revert to the current state of matters.
>> When TD_IS_INPANIC is introduced and stop_cpus_on_panic==1, then there will be
>> only one thread left running after panic, that will be the thread that called
>> panic, checking TDF_INPANIC just doesn't add anything.
>
> Won't the scheduler still run even if other CPUs are halted?  Is there
> any intent to prevent switching to another thread?  (I suppose this
> could be achieved by setting td_critnest++ and wouldn't require a
> flag).
>

I think it is much better to disable interrupts, in order to prevent
fast handlers "preemption" rather than just avoiding to be
rescheduled.

Attilio


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