From: Dario Faggioli <raistlin@linux.it>
To: Lucas De Marchi <lucas.de.marchi@gmail.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>,
linux-kernel <linux-kernel@vger.kernel.org>,
Steven Rostedt <rostedt@goodmis.org>,
Gregory Haskins <ghaskins@novell.com>,
Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@elte.hu>,
Mike Galbraith <efault@gmx.de>,
Dhaval Giani <dhaval@retis.sssup.it>,
Fabio Checconi <fabio@gandalf.sssup.it>,
Darren Hart <darren@dvhart.com>, oleg <oleg@redhat.com>,
paulmck <paulmck@linux.vnet.ibm.com>,
pjt@google.com, bharata@linux.vnet.ibm.co
Subject: Re: [RFC][PATCH 0/3] Refactoring sched_entity and sched_rt_entity.
Date: Tue, 04 Jan 2011 19:57:10 +0100 [thread overview]
Message-ID: <1294167430.6169.227.camel@Palantir> (raw)
In-Reply-To: <AANLkTi=G1b3OHH1ZUGCcL+nnb3LaeUDMWsXk8z+FzWT2@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2338 bytes --]
On Tue, 2011-01-04 at 16:29 -0200, Lucas De Marchi wrote:
> > Mmm... do I? While I'm cloning your git, could you elaborate a bit on
> > why, because I don't seem to see that... :-P
>
> Suppose a RT task blocks on a PI-mutex, the lock owner will be boosted
> to RT and go through a class change in rt_mutex_setprio().
> Since now a class change reinitializes the class-specific, if fair and
> rt fields are on the same memory space, we need to save the
> sched_fair_entity before changing the class to RT and put it again
> when going back to the fair class.
>
Well, I know, but you're deactivating+dequeueing and then
activating+enqueueing it back and forth within the proper scheduling
class, so that shouldn't be a big deal...
Actually, the point might be that forgetting something like, e.g.,
vruntime would then lead to unexpected behaviour when the task is back
to fair scheduling, but do we need to cache the whole sched_[cfs|
fair]_entity for that?
> Quoting Peter about this:
>
> [ Initially I was thinking not, because the task slept we'll have to
> reinsert it in the rb-tree anyway, but upon further consideration
> that'll loose the old vruntime setting, which can lead to an unseemly
> gain of time in place_entity()'s never backward check failing.
>
> So yes, we'd have to place a copy of the old sched_entity in struct
> rt_mutex_waiter, not very hard to do. ]
>
Ok, exactly, I now see that, and it's probably not hard to do... But I'm
now thinking of how many fields must be saved to avoid this. Surely, not
these ones:
...
struct rb_node run_node;
struct list_head group_node;
#ifdef CONFIG_FAIR_GROUP_SCHED
struct sched_cfs_entity *parent;
/* rq on which this entity is (to be) queued: */
struct cfs_rq *cfs_rq;
/* rq "owned" by this entity/group: */
struct cfs_rq *my_q;
#endif
...
I'll double check, but if it's just a matter of vruntime and a couple of
other u64, isn't it worth to just save them?
Thanks and Regards,
Dario
--
<<This happens because I choose it to happen!>> (Raistlin Majere)
----------------------------------------------------------------------
Dario Faggioli, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)
http://retis.sssup.it/people/faggioli -- dario.faggioli@jabber.org
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
prev parent reply other threads:[~2011-01-04 18:57 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-04 15:55 [RFC][PATCH 0/3] Refactoring sched_entity and sched_rt_entity Dario Faggioli
2011-01-04 16:00 ` [RFC][PATCH 1/3] sched: rename sched_entity to sched_cfs_entity Dario Faggioli
2011-01-04 16:01 ` [RFC][PATCH 2/3] sched: make `struct sched_entity' independent from the scheduling class Dario Faggioli
2011-01-04 16:02 ` [RFC][PATCH 3/3] sched: beautify access to some common fields Dario Faggioli
2011-01-04 16:18 ` [RFC][PATCH 0/3] Refactoring sched_entity and sched_rt_entity Lucas De Marchi
2011-01-04 18:31 ` Dario Faggioli
2011-01-04 16:19 ` Peter Zijlstra
2011-01-04 18:11 ` Dario Faggioli
2011-01-04 19:26 ` Peter Zijlstra
2011-01-04 16:37 ` Lucas De Marchi
2011-01-04 16:41 ` Peter Zijlstra
2011-01-04 18:08 ` Dario Faggioli
2011-01-04 17:58 ` Dario Faggioli
2011-01-04 18:29 ` Lucas De Marchi
2011-01-04 18:57 ` Dario Faggioli [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=1294167430.6169.227.camel@Palantir \
--to=raistlin@linux.it \
--cc=a.p.zijlstra@chello.nl \
--cc=bharata@linux.vnet.ibm.co \
--cc=darren@dvhart.com \
--cc=dhaval@retis.sssup.it \
--cc=efault@gmx.de \
--cc=fabio@gandalf.sssup.it \
--cc=ghaskins@novell.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lucas.de.marchi@gmail.com \
--cc=mingo@elte.hu \
--cc=oleg@redhat.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=pjt@google.com \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
/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.