From: Peter Zijlstra <peterz@infradead.org>
To: Raistlin <raistlin@linux.it>
Cc: Soumya K S <ssks.mt@gmail.com>,
linux-kernel@vger.kernel.org, mingo@redhat.com,
Dhaval Giani <dhaval.giani@gmail.com>,
Thomas Gleixner <tglx@linutronix.de>,
Claudio Scordino <claudio@evidence.eu.com>,
michael trimarchi <trimarchi@gandalf.sssup.it>,
Juri Lelli <juri.lelli@gmail.com>
Subject: Re: [PATCH] DRTL kernel 2.6.32-rc3 : SCHED_EDF, DI RT-Mutex, Deadline Based Interrupt Handlers
Date: Tue, 10 Nov 2009 15:34:48 +0100 [thread overview]
Message-ID: <1257863689.4108.441.camel@laptop> (raw)
In-Reply-To: <1256747090.25821.367.camel@Palantir>
On Wed, 2009-10-28 at 17:24 +0100, Raistlin wrote:
> Relying on userspace to do things
> 'intelligently' is something I'm not sure I would do, especially in a so
> much general purpose OS like Linux, used in so much different contexts.
> But, again, that's only my opinion. :-)
I'd put it even stronger, relying on userspace to do something
intelligent is utterly stupid. We have to assume userspace is hostile
and out to get you.
Therefore I fully support the model that puts admission control into the
kernel, because that provides isolation between, and guarantees to
applications.
Not providing this, and having no overload protection is one of the
biggest failures of SCHED_FIFO/RR.
On Tue, 2009-11-10 at 19:33 +0530, Soumya K S wrote:
> Hmm I guess you too are "totally" dependent on user giving you the
> right parameters _intelligently_ (deadline / budget)... I guess we are
> not too different there expecting the users to be _aware_ ..!
The difference is that if A messes up its own parameters only A suffers
and the rest of the system continues to work as expected.
With your approach anything is out the window.
So yes, userspace needs to be aware, but a task can only screw itself,
not everybody else, which is a very important feature.
@ DRTL folks:
If you want deadline based scheduling (it appears you do) I suggest you
start helping out Dario, your proposal isn't going to happen.
next prev parent reply other threads:[~2009-11-10 14:34 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <e932a33e0910210833j1fab6129m23b55101c5978c4a@mail.gmail.com>
2009-10-21 15:38 ` [PATCH] DRTL kernel 2.6.32-rc3 : SCHED_EDF, DI RT-Mutex, Deadline Based Interrupt Handlers Soumya K S
2009-10-22 7:54 ` Raistlin
2009-10-22 14:42 ` Soumya K S
2009-10-25 8:46 ` Raistlin
2009-10-28 14:15 ` Soumya K S
2009-10-28 16:24 ` Raistlin
2009-11-10 14:03 ` Soumya K S
2009-11-10 14:34 ` Peter Zijlstra [this message]
2009-10-22 9:33 ` Claudio Scordino
[not found] ` <e932a33e0910220738v3c612d68ve902a770ab0928f4@mail.gmail.com>
2009-10-22 14:40 ` Soumya K S
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=1257863689.4108.441.camel@laptop \
--to=peterz@infradead.org \
--cc=claudio@evidence.eu.com \
--cc=dhaval.giani@gmail.com \
--cc=juri.lelli@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=raistlin@linux.it \
--cc=ssks.mt@gmail.com \
--cc=tglx@linutronix.de \
--cc=trimarchi@gandalf.sssup.it \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox