Jan Kiszka wrote:
> Philippe Gerum wrote:
>> This makes sense. I'm currently testing the patch below which implements
>> a close variant of Gilles's proposal. Could you try it as well, to see
>> if things improve?
>> http://git.xenomai.org/?p=xenomai-rpm.git;a=commit;h=3200660065146915976c193387bf0851be10d0cc
> Will test ASAP.

Works fine here so far.


>> The logic makes sure that we can keep calling xnsched_set_resched() then
>> xnpod_schedule() outside of the same critical section, which is
>> something we need. Otherwise this requirement would extend to
>> xnpod_suspend/resume_thread(), which is not acceptable.
> I still wonder if things can't be even simpler. What is the purpose of
> xnsched_t::resched? I first thought it's just there to coalesce multiple
> remote reschedule requests, thus IPIs triggered by one CPU over
> successive wakeups etc. If that is true, why going through resched for
> local changes, why not setting XNRESCHED directly? And why not setting
> the remote XNRESCHED instead of remote's xnsched_t::resched?
> Jan

Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Xenomai-core mailing list

Reply via email to