From: Peter Zijlstra <peterz@infradead.org>
To: Primiano Tucci <p.tucci@gmail.com>
Cc: rostedt@goodmis.org, linux-kernel@vger.kernel.org,
tglx <tglx@linutronix.de>
Subject: Re: Considerations on sched APIs under RT patch
Date: Wed, 21 Apr 2010 21:57:13 +0200 [thread overview]
Message-ID: <1271879833.1776.186.camel@laptop> (raw)
In-Reply-To: <x2mc5b2c05b1004211224s7825933dh531f2ed030610e9e@mail.gmail.com>
On Wed, 2010-04-21 at 21:24 +0200, Primiano Tucci wrote:
> Is it sure that calling a scheduler api won't induce a re-scheduling
> of the caller process (e.g. as in the case of a lock held by another
> processor)? It would be very unpleasant if the scheduling apis can
> induce re-scheduling, making the realization of a Real Time scheduling
> infrastructure completely un-deterministic.
No, any syscall can end up blocking/scheduling there are no exceptions.
But blocking doesn't mean its non-deterministic, esp. when coupled with
things like PI.
But you do have to treat system resources as such, that is they can (and
will) create cross-cpu dependencies, if you do not take that into
account you will of course be surprised.
next prev parent reply other threads:[~2010-04-21 19:57 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-19 20:48 Considerations on sched APIs under RT patch Primiano Tucci
2010-04-20 9:20 ` Peter Zijlstra
2010-04-20 21:56 ` Primiano Tucci
2010-04-20 23:00 ` Steven Rostedt
2010-04-21 5:16 ` Primiano Tucci
2010-04-21 8:49 ` Peter Zijlstra
2010-04-21 12:46 ` Steven Rostedt
2010-04-21 19:24 ` Primiano Tucci
2010-04-21 19:57 ` Peter Zijlstra [this message]
2010-04-21 20:38 ` Primiano Tucci
2010-04-21 20:58 ` Peter Zijlstra
2010-04-22 13:20 ` Steven Rostedt
2010-04-22 13:50 ` Primiano Tucci
2010-04-22 13:57 ` Peter Zijlstra
2010-04-22 15:40 ` Primiano Tucci
2010-04-22 16:28 ` Peter Zijlstra
2010-04-22 17:48 ` Bjoern Brandenburg
2010-04-22 19:33 ` Primiano Tucci
2010-04-21 12:56 ` Peter Zijlstra
2010-04-27 13:18 ` Thomas Gleixner
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=1271879833.1776.186.camel@laptop \
--to=peterz@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=p.tucci@gmail.com \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
/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.