xnsched_kick

[Jan Kiszka]

On 21.05.21 16:41, Philippe Gerum via Xenomai wrote:
> 
> Marco Barletta via Xenomai <xenomai at xenomai.org> writes:
> 
>> Hi everyone, related to the sched_quota patch I posted about one week ago.
>> I'm trying to understand why xnsched_kick is needed, in which situation is
>> called. Reading the code it seems it's called when there's a xeno thread
>> that must be downgraded and scheduled in Linux, but I didn't understand why
>> there's the need to run to complention without respecting group budget. Can
>> you help me?
>> Best regards.
> 
> When a thread is forcibly kicked out of oob context by the core, this
> means that it ought to move quickly to in-band context in order to
> respond to a pending kernel event, such as handling a signal. e.g. we
> use xnthread_kick() to force a thread which is being sent a SIGTRAP
> signal by a debugger, to receive that signal - otherwise bad things may
> happen kernel-wise.
> 
> With that in mind, what would happen if a SCHED_QUOTA thread is kicked
> out, but belongs to a group which is given no runtime credit? Typically,
> the user might set the quota limit to 0% for any group. In that case,
> any thread from that group would be prevented from resuming, therefore
> could not honor the request for switching back to in-band mode asap,
> which is the only way to secure the handling of a pending kernel event
> (again, such as a pending signal). To prevent this, every scheduler
> module which might cause a thread to have no execution time due to its
> policy must implement the sched_kick handler so that we have a bypass
> method for that particular case.
> 
> SCHED_TP has no sched_kick handler because under such a policy, there is
> no provision for permanently depriving a thread of execution time. At
> worst, that thread would have to wait for a complete global time frame
> to elapse before receiving renewed runtime credit. This implies that we
> do expect the global time frame not to last for an unreasonably long
> time, which has been a safe bet for SCHED_TP so far.
> 

Thanks for the explanation! Would someone like to write a comment patch
for the quota sched handler?

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux