[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTi=G1b3OHH1ZUGCcL+nnb3LaeUDMWsXk8z+FzWT2@mail.gmail.com>
Date: Tue, 4 Jan 2011 16:29:38 -0200
From: Lucas De Marchi <lucas.de.marchi@...il.com>
To: Dario Faggioli <raistlin@...ux.it>
Cc: Peter Zijlstra <a.p.zijlstra@...llo.nl>,
linux-kernel <linux-kernel@...r.kernel.org>,
Steven Rostedt <rostedt@...dmis.org>,
Gregory Haskins <ghaskins@...ell.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...e.hu>, Mike Galbraith <efault@....de>,
Dhaval Giani <dhaval@...is.sssup.it>,
Fabio Checconi <fabio@...dalf.sssup.it>,
Darren Hart <darren@...art.com>, oleg <oleg@...hat.com>,
paulmck <paulmck@...ux.vnet.ibm.com>, pjt@...gle.com,
bharata@...ux.vnet.ibm.co
Subject: Re: [RFC][PATCH 0/3] Refactoring sched_entity and sched_rt_entity.
On Tue, Jan 4, 2011 at 15:58, Dario Faggioli <raistlin@...ux.it> wrote:
> On Tue, 2011-01-04 at 14:37 -0200, Lucas De Marchi wrote:
>> > Suggestions on how to deal with that will be appreciated.
>>
>> Don't forget the PI case too. You will need to change
>> rt_mutex_setprio() to keep a copy of sched_cfs_entity in struct
>> rt_mutex_waiter.
>>
> 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.
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. ]
As a side-note: irc this is one thing i didn't do when i prepared that patches.
Lucas De Marchi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists