public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Raistlin <raistlin@linux.it>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Jamie Lokier <jamie@shareable.org>,
	sen wang <wangsen.linux@gmail.com>,
	mingo@elte.hu, akpm@linux-foundation.org, kernel@kolivas.org,
	npiggin@suse.de, arjan@infradead.org,
	linux-arm-kernel@lists.arm.linux.org.uk,
	linux-kernel@vger.kernel.org,
	Tommaso Cucinotta <tommaso.cucinotta@sssup.it>
Subject: Re: report a bug about sched_rt
Date: Sat, 25 Jul 2009 14:19:14 +0200	[thread overview]
Message-ID: <1248524354.8429.100.camel@Palantir> (raw)
In-Reply-To: <1248451279.6987.138.camel@twins>

[-- Attachment #1: Type: text/plain, Size: 1942 bytes --]

On Fri, 2009-07-24 at 18:01 +0200, Peter Zijlstra wrote:
> For bugs the throttle works, like I said a well functioning system is
> not supposed to hit the throttle, obviously a bug precludes the well
> functioning qualification :-)
> 
Yes, I also think a bandwidth isolation/throttling mechanism could help
a lot either with bugs or when you need hard real-time, soft real-time
and non real-time applications to live together in one single system
such as Linux is --or is about to become.

> Unpredictable calculation times can be dealt with on the application
> design level, for example using techniques such as outlined here:
> 
>   http://feanor.sssup.it/~faggioli/papers/OSPERT-2009-dlexception.pdf
> 
Thanks Peter! :-)

We're getting more citation in this ML than in 'our' academic world...
I'm not sure it is useful for our PhD and research career, but, indeed,
I like that very much anyway! :-P

The mechanism proposed in that paper is one way for providing developers
with the capability of specifying some typical real time "attributes" of
an application (or part of it), such as deadline and/or expected (worst
case?) execution time.

It is probably not always the best way of doing, but it's something we
think it could be useful somewhere. Therefore, we are still working on
it, e.g., improving timer resolution, adding the support for new
semantic and programming models, etc. Moreover, we are open to any
suggestion and contribution about this work, especially from the
community!

> These really are things you should know about before writing an RT
> application ;-)
:-D

Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
----------------------------------------------------------------------
Dario Faggioli, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa  (Italy)

http://blog.linux.it/raistlin / raistlin@ekiga.net /
dario.faggioli@jabber.org

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

  parent reply	other threads:[~2009-07-25 12:19 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-24 10:57 report a bug about sched_rt sen wang
2009-07-24 12:14 ` Peter Zijlstra
2009-07-24 13:04   ` sen wang
2009-07-24 13:14     ` Peter Zijlstra
2009-07-24 13:26       ` sen wang
2009-07-24 13:33         ` Peter Zijlstra
2009-07-24 13:44           ` sen wang
2009-07-24 13:54             ` Peter Zijlstra
2009-07-24 14:04               ` sen wang
2009-07-24 14:48                 ` Peter Zijlstra
2009-07-24 14:53                   ` sen wang
2009-07-24 15:07                   ` sen wang
2009-07-24 15:24                     ` Peter Zijlstra
2009-07-24 15:43                       ` sen wang
2009-07-24 15:34                     ` Thomas Gleixner
2009-07-25 11:12                     ` Raistlin
2009-07-24 14:24               ` sen wang
2009-07-24 14:48                 ` Peter Zijlstra
2009-07-24 15:02                   ` sen wang
2009-07-24 15:40                   ` Jamie Lokier
2009-07-24 16:01                     ` Peter Zijlstra
2009-07-24 23:30                       ` Jamie Lokier
2009-07-25  5:22                         ` Bill Gatliff
2009-07-25 22:48                           ` Jamie Lokier
2009-07-26  2:44                             ` Bill Gatliff
2009-07-26 19:03                               ` Jamie Lokier
2009-07-27 10:45                                 ` Peter Zijlstra
2009-07-27 13:35                                 ` Bill Gatliff
2009-07-25 12:33                         ` Raistlin
2009-07-25 14:58                           ` Tommaso Cucinotta
2009-07-25 12:19                       ` Raistlin [this message]
2009-07-25 22:54                         ` Jamie Lokier
2009-07-25 23:24                           ` Tommaso Cucinotta
2009-07-25 11:10         ` Raistlin
     [not found]           ` <454c71700907250429i1c77658bt6d65b02f08a29f4a@mail.gmail.com>
2009-07-25 23:01             ` Jamie Lokier
2009-07-24 14:28 ` Arjan van de Ven
2009-07-26  3:55   ` sen wang

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=1248524354.8429.100.camel@Palantir \
    --to=raistlin@linux.it \
    --cc=akpm@linux-foundation.org \
    --cc=arjan@infradead.org \
    --cc=jamie@shareable.org \
    --cc=kernel@kolivas.org \
    --cc=linux-arm-kernel@lists.arm.linux.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=npiggin@suse.de \
    --cc=peterz@infradead.org \
    --cc=tommaso.cucinotta@sssup.it \
    --cc=wangsen.linux@gmail.com \
    /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