All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: vatsa@in.ibm.com
Cc: bharata@linux.vnet.ibm.com, linux-kernel@vger.kernel.org,
	Ingo Molnar <mingo@elte.hu>,
	Dhaval Giani <dhaval@linux.vnet.ibm.com>
Subject: Re: [PATCH] sched: Don't allow priority switch to realtime when the task doesn't belong to init_task_group and when CONFIG_RT_GROUP_SCHED isn't set
Date: Mon, 24 Nov 2008 19:46:37 +0100	[thread overview]
Message-ID: <1227552397.4259.504.camel@twins> (raw)
In-Reply-To: <20081124170535.GE5451@linux.vnet.ibm.com>

On Mon, 2008-11-24 at 22:35 +0530, Srivatsa Vaddagiri wrote:
> On Mon, Nov 24, 2008 at 09:32:06AM +0100, Peter Zijlstra wrote:
> > >  And may be as Ingo
> > > suggested they should be moved to init_task_group.
> > 
> > Bzzt, wrong! They should not be moved to any group, they cannot be moved
> > to any group, as they are group invariant.
> 
> Though what you say makes sense, the confusion arises from existing
> cgroup<->scheduler interface, which can end up showing the above
> single-set of RT-tasks to be split into multiple sets.
> 
> RT Tasks -> {RT0, RT1}
> 
> can be shown as:
> 
> 	/a/tasks {RT0, ...}
> 	/b/tasks {RT1, ...}
> 
> Does this cause any problems? Perhaps no, just seems odd ..
> 
> Fixing this oddity of representing single RT-tasks set as multiple is not a 
> cgroup issue IMHO.

I'm fine with just not showing RT tasks in cgroup:cpu/tasks.

> P.S :- If eventually RT_GROUP_SCHED will be merged with FAIR_GROUP_SCHED, then 
> it may make sense for us to just ignore this oddity for timebeing and look 
> forward to the options being merged.

Right, that might take a bit of time still as RT_GROUP needs a deadline
scheduler to be complete.


      reply	other threads:[~2008-11-24 18:46 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-20  6:18 [PATCH] sched: Don't allow priority switch to realtime when the task doesn't belong to init_task_group and when CONFIG_RT_GROUP_SCHED isn't set Bharata B Rao
2008-11-20  7:58 ` Ingo Molnar
2008-11-20  8:03   ` Dhaval Giani
2008-11-20  8:17     ` Ingo Molnar
2008-11-20  8:19   ` Bharata B Rao
2008-11-23  1:11 ` Peter Zijlstra
2008-11-24  3:58   ` Bharata B Rao
2008-11-24  8:32     ` Peter Zijlstra
2008-11-24  8:46       ` Dhaval Giani
2008-11-24  9:06         ` Peter Zijlstra
2008-11-24 15:24           ` Chris Friesen
2008-11-24 15:36             ` Peter Zijlstra
2008-11-25 18:51               ` Chris Friesen
2008-11-25 20:17                 ` Peter Zijlstra
2008-11-24 17:05       ` Srivatsa Vaddagiri
2008-11-24 18:46         ` 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=1227552397.4259.504.camel@twins \
    --to=a.p.zijlstra@chello.nl \
    --cc=bharata@linux.vnet.ibm.com \
    --cc=dhaval@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=vatsa@in.ibm.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 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.