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 Xenomaifirstname.lastname@example.org https://mail.gna.org/listinfo/xenomai-core