* xnsched_kick @ 2021-05-21 11:21 Marco Barletta 2021-05-21 11:47 ` xnsched_kick Jan Kiszka 2021-05-21 14:41 ` xnsched_kick Philippe Gerum 0 siblings, 2 replies; 5+ messages in thread From: Marco Barletta @ 2021-05-21 11:21 UTC (permalink / raw) To: xenomai 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. -- Marco Barletta ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: xnsched_kick 2021-05-21 11:21 xnsched_kick Marco Barletta @ 2021-05-21 11:47 ` Jan Kiszka 2021-05-21 14:41 ` xnsched_kick Philippe Gerum 1 sibling, 0 replies; 5+ messages in thread From: Jan Kiszka @ 2021-05-21 11:47 UTC (permalink / raw) To: Marco Barletta, xenomai, Philippe Gerum On 21.05.21 13:21, Marco Barletta via Xenomai wrote: > 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? I think that is a valid question because sched-tp does not implement such a scheme. Basic information can be found in https://source.denx.de/Xenomai/xenomai/-/commit/cee27b2945f92857308dcde619a3e64607b5327e I would forward this for further background to the designer... Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: xnsched_kick 2021-05-21 11:21 xnsched_kick Marco Barletta 2021-05-21 11:47 ` xnsched_kick Jan Kiszka @ 2021-05-21 14:41 ` Philippe Gerum 2021-05-21 15:13 ` xnsched_kick Jan Kiszka 1 sibling, 1 reply; 5+ messages in thread From: Philippe Gerum @ 2021-05-21 14:41 UTC (permalink / raw) To: Marco Barletta; +Cc: xenomai Marco Barletta via Xenomai <xenomai@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. -- Philippe. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: xnsched_kick 2021-05-21 14:41 ` xnsched_kick Philippe Gerum @ 2021-05-21 15:13 ` Jan Kiszka 2021-05-21 22:04 ` xnsched_kick Marco Barletta 0 siblings, 1 reply; 5+ messages in thread From: Jan Kiszka @ 2021-05-21 15:13 UTC (permalink / raw) To: Philippe Gerum, Marco Barletta; +Cc: xenomai On 21.05.21 16:41, Philippe Gerum via Xenomai wrote: > > Marco Barletta via Xenomai <xenomai@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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: xnsched_kick 2021-05-21 15:13 ` xnsched_kick Jan Kiszka @ 2021-05-21 22:04 ` Marco Barletta 0 siblings, 0 replies; 5+ messages in thread From: Marco Barletta @ 2021-05-21 22:04 UTC (permalink / raw) To: Jan Kiszka; +Cc: Philippe Gerum, xenomai I want to thank you for time and patience as well! Il giorno ven 21 mag 2021 alle ore 17:13 Jan Kiszka <jan.kiszka@siemens.com> ha scritto: > On 21.05.21 16:41, Philippe Gerum via Xenomai wrote: > > > > Marco Barletta via Xenomai <xenomai@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 > -- Marco Barletta ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2021-05-21 22:04 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-05-21 11:21 xnsched_kick Marco Barletta 2021-05-21 11:47 ` xnsched_kick Jan Kiszka 2021-05-21 14:41 ` xnsched_kick Philippe Gerum 2021-05-21 15:13 ` xnsched_kick Jan Kiszka 2021-05-21 22:04 ` xnsched_kick Marco Barletta
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.