All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <a.p.zijlstra-/NLkJaSkS4VmR6Xm/wNWPw@public.gmane.org>
To: Dhaval Giani <dhaval-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
Cc: containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org
Subject: Re: Cgroups RT scheduling
Date: Fri, 11 Sep 2009 13:47:20 +0200	[thread overview]
Message-ID: <1252669640.7126.29.camel@laptop> (raw)
In-Reply-To: <20090911112352.GH4474-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>

On Fri, 2009-09-11 at 16:53 +0530, Dhaval Giani wrote:
> [Adding peterz to the cc]
> 
> On Wed, Sep 09, 2009 at 04:49:52PM +0100, Rolando Martins wrote:
> > Hi,
> > 
> > I would like to confirm the following:
> > cpuset.sched_load_balance doesn't work with RT, right?

It does.

> > You cannot have tasks for sub-domain 2 to utilize bandwidth of
> > sub-domain 3, right?

Depends on what you do, for some contorted reason we have 2 cpu control
groups, cpusets and this other thing.

I'm still wanting to fold them into one, this confusion is in part
because of that train-wreck.

You can place a task in one cpuset cgroup and in another scheduler
cgroup - but yeah, that does interact funny with the load-balancer.

> > 
> >                               __1__
> >                              /        \
> >                             2         3
> >                       (50% rt)  (50% rt )
> > 
> > For my application domain;) it would be interesting to have
> > rt_runtime_ns as a min. of allocated rt and not a max.
> > Ex. If an application of domain 2 needs to go up to 100% and domain 3
> > is idle, then it would be cool to let it utilize the full bandwidth.
> > (we also could have a hard upper limit in each sub-domain, like
> > hard_up=0.8, i.e. even if we could get 100%, we will only utilize
> > 80%).

This doesn't sound a like a real-time application.

Variable bandwidth is useless for determinism.

      parent reply	other threads:[~2009-09-11 11:47 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-09 15:49 Cgroups RT scheduling Rolando Martins
     [not found] ` <b6a2d2e20909090849m16a9f452h353d5a75ee61c625-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-09-11 11:23   ` Dhaval Giani
     [not found]     ` <20090911112352.GH4474-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2009-09-11 11:47       ` Peter Zijlstra [this message]

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=1252669640.7126.29.camel@laptop \
    --to=a.p.zijlstra-/nlkjasks4vmr6xm/wnwpw@public.gmane.org \
    --cc=containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org \
    --cc=dhaval-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org \
    /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.