Jan Kiszka wrote:
>>> At first sight, here you are more breaking things than cleaning them.
>> Still, it has the SMP record for my test program, still runs with ftrace
>> on (after 2 hours, where it previously failed after maximum 23 minutes).
>
> My version was indeed still buggy, I'm reworking it ATM.
>
>> If I get the gist of Jan's changes, they are (using the IPI to transfer
>> one bit of information: your cpu needs to reschedule):
>>
>> xnsched_set_resched:
>> - setbits((__sched__)->status, XNRESCHED);
>>
>> xnpod_schedule_handler:
>> + xnsched_set_resched(sched);
>>
>> If you (we?) decide to keep the debug checks, under what circumstances
>> would the current check trigger (in laymans language, that I'll be able
>> to understand)?
>
> That's actually what /me is wondering as well. I do not see yet how you
> can reliably detect a missed reschedule reliably (that was the purpose
> of the debug check) given the racy nature between signaling resched and
> processing the resched hints.
The purpose of the debugging change is to detect a change of the
scheduler state which was not followed by setting the XNRESCHED bit.
Getting it to work is relatively simple: we add a "scheduler change set
remotely" bit to the sched structure which is NOT in the status bit, set
this bit when changing a remote sched (under nklock). In the debug check
code, if the scheduler state changed, and the XNRESCHED bit is not set,
only consider this a but if this new bit is not set. All this is
compiled out if the debug is not enabled.
I will try and work on this this week-end.
--
Gilles.
_______________________________________________
Xenomai-core mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-core
