LKML Archive on lore.kernel.org help / color / mirror / Atom feed
From: Peter Zijlstra <a.p.zijlstra@chello.nl> To: Paul Menage <menage@google.com> Cc: Ingo Molnar <mingo@elte.hu>, linux-kernel@vger.kernel.org, tong.n.li@intel.com Subject: Re: [PATCH 3/8] sched: rt-group: interface Date: Sat, 23 Feb 2008 21:26:29 +0100 [thread overview] Message-ID: <1203798389.6242.98.camel@lappy> (raw) In-Reply-To: <6599ad830802231202q6584557fte44f4976eacc6e89@mail.gmail.com> On Sat, 2008-02-23 at 12:02 -0800, Paul Menage wrote: > On Sat, Feb 23, 2008 at 11:57 AM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote: > > > If so, could we avoid that problem by using 0 rather than -1 as the > > > "unlimited" value? It looks from what I've read in the Documentation > > > changes as though 0 isn't really a meaningful value. > > > > 0 means no time, quite useful and clearly distinct from inf. time. > > > > So a real-time task in a cgroup with a 0 rt_runtime can be in the R > state but never actually get to run? OK, if people need to be able to > do that then fair enough. Yeah, its an awkward situation, and we refuse new rt tasks in such groups. But the 0 value is needed so you can have groups that don't participate in the realtime scheduling because we enforce a schedulalbility constraint over the groups. Each group has a runtime ratio, namely: rt_runtime / rt_period. The sum of this ratio over all groups must be smaller or equal to the global ratio which must be smaller or equal to 1. > In that case I guess I'll have to add signed versions of the > read_uint/write_uint methods. Yes, I looked at that, I found the interface somewhat unfortunate, it would mean growing the struct with two more function pointers. Perhaps a read and write function with abstract data would be better suited. That would allow for this and more. Sadly it looses type information.
next prev parent reply other threads:[~2008-02-23 20:26 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <20080204210258.118479000@chello.nl> 2008-02-04 21:02 ` [PATCH 1/8] sched: fix incorrect irq lock usage in normalize_rt_tasks() Peter Zijlstra 2008-02-04 21:03 ` [PATCH 2/8] sched: rt-group: deal with PI Peter Zijlstra 2008-02-04 21:03 ` [PATCH 3/8] sched: rt-group: interface Peter Zijlstra 2008-02-06 1:31 ` Randy Dunlap 2008-02-23 19:48 ` Paul Menage 2008-02-23 19:57 ` Peter Zijlstra 2008-02-23 20:02 ` Paul Menage 2008-02-23 20:26 ` Peter Zijlstra [this message] 2008-02-23 20:36 ` Paul Menage 2008-02-04 21:03 ` [PATCH 4/8] sched: rt-group: make rt groups scheduling configurable Peter Zijlstra 2008-02-04 21:03 ` [PATCH 5/8] sched: rt-group: clean up the ifdeffery Peter Zijlstra 2008-02-04 21:03 ` [PATCH 6/8] sched: rt-group: refure unrunnable tasks Peter Zijlstra 2008-02-04 21:03 ` [PATCH 7/8] sched: rt-group: synchonised bandwidth period Peter Zijlstra 2008-02-04 21:03 ` [PATCH 8/8] sched: rt-group: smp balancing Peter Zijlstra
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=1203798389.6242.98.camel@lappy \ --to=a.p.zijlstra@chello.nl \ --cc=linux-kernel@vger.kernel.org \ --cc=menage@google.com \ --cc=mingo@elte.hu \ --cc=tong.n.li@intel.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: linkBe 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; as well as URLs for NNTP newsgroup(s).