public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Jamie Lokier <jamie@shareable.org>
Cc: Bill Gatliff <bgat@billgatliff.com>,
	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 <cucinotta@sssup.it>
Subject: Re: report a bug about sched_rt
Date: Mon, 27 Jul 2009 12:45:45 +0200	[thread overview]
Message-ID: <1248691545.6987.1587.camel@twins> (raw)
In-Reply-To: <20090726190343.GB12916@shareable.org>

On Sun, 2009-07-26 at 20:03 +0100, Jamie Lokier wrote:

> So RT-bandwidth would be nice for those threaded interrupts.

No, a different/better scheduling policy would be - maybe.

People mentioned SCHED_SPORADIC, but I really really dislike that
because for the actual sporadic task model we can do so much better
using deadline schedulers.

Furthermore, SCHED_SPORADIC as specified by POSIX is a useless piece of
crap, so we would have to deviate from POSIX, which would create
confusion -- although good documentation might help a little here.

The current RT-bandwidth comes from the RT cgroup code, and its only
purpose in life is to provide isolation between multiple groups through
guaranteeing the bandwidth of others by hard limiting. It does that.

It's certainly not flawless, in fact its not what I would call complete
(hence its still EXPERIMENTAL status), but Fabio is working on
implementing a deadline H-CBS for this, which would greatly improve the
situation.

Extending the deadline model with a soft mode might be useful as
mentioned by Tommaso, but I would only be looking at that after we've
completed work on the normal deadline bits (both group and task). And
then we'd have to consistently and full integrate it with both.


  reply	other threads:[~2009-07-27 10:43 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 [this message]
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
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=1248691545.6987.1587.camel@twins \
    --to=peterz@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=arjan@infradead.org \
    --cc=bgat@billgatliff.com \
    --cc=cucinotta@sssup.it \
    --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=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