All of lore.kernel.org
 help / color / mirror / Atom feed
From: Philippe Gerum <rpm@xenomai.org>
To: Marco Barletta <barlettamarco8@gmail.com>
Cc: xenomai@xenomai.org
Subject: Re: xnsched_kick
Date: Fri, 21 May 2021 16:41:17 +0200	[thread overview]
Message-ID: <87zgwocfoy.fsf@xenomai.org> (raw)
In-Reply-To: <CAK6DXL2H4OuDGehPaHwDtArtg=Y2H+xs6eC49_9NueYPtxRCHA@mail.gmail.com>


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.


  parent reply	other threads:[~2021-05-21 14:41 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2021-05-21 15:13   ` xnsched_kick Jan Kiszka
2021-05-21 22:04     ` xnsched_kick Marco Barletta

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87zgwocfoy.fsf@xenomai.org \
    --to=rpm@xenomai.org \
    --cc=barlettamarco8@gmail.com \
    --cc=xenomai@xenomai.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.