Re: [PATCH 2/3] RT: Cache cpus_allowed weight for optimizing migration

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: Gregory Haskins
Date: Thursday, October 25, 2007 - 11:51 am

On Thu, 2007-10-25 at 11:48 -0400, Steven Rostedt wrote:
--------
long clone_flags,
ask_t new_mask)

I think you are misunderstanding the code here.  The only optimization
is that I didn't want to force every sched_class to define a default
set_cpus_allowed member-fn.  So instead, it first checks if its defined
and invokes it if true.  Else, the default behavior is to assign the
mask and calculate the weight.

If you look at the one and only implementation of this function
(sched_rt.c:set_cpus_allowed_rt()), it also performs the assignment and
calcs the mask.

Or did I misunderstand your objection?

, struct rq *rq)
, struct rq *rq)
rt(struct rq *rq,
get_rq)
struct *task,

I disagree, but I admit it is not apparent at this level of the series
why.  The reason has to do with optimizing the wakeup path.  Unless I am
missing something, I think this placement is optimal, and that will
hopefully become apparent when you see the rest of my series.


struct *task,

Reducing code duplication is an effort to mitigate error propagation,
not increase it ;)


This was intentional, but perhaps I should have been more explicit on
the reason why.  This is again related to future optimizations that I
have yet to reveal.  Namely, this code path can be invoked before the
task has been woken up, and it is therefore normal for it to not be on a
RQ.


Hmm.. This is a good point.  Perhaps we should check to see that the
task doesnt change state instead of if its on a RQ.


You aren't the first person to say something like that, and I always
scratch my head at that one.  It *is* open..its right there -40 lines
from where it used to be.  Its not like I gave you a obfuscated .o
blackbox ;)


Agreed.  You weren't aware of my issue, as I wasn't aware of yours.  I
think that means we both failed to comment tricky code properly ;)

k_struct *p)
ask)
tly =3D {

?  I don't understand what you mean.  Are you referring to PI boosting?
What does that have to do with the mask?

Are you referring to when we change the mask?  We already invoke this
handler from the sched.c:set_cpus_allowed().  Can you clarify this
point?


It is.  Im just lazy and had the default case handled inside the
sched_c:set_cpus_allowed() call.  Perhaps I should just let all
sched_classes define a handler instead of such trickery.


Well, at least for what I am designing here, we are already covered.  If
the task changes class, it would be dequeued in one class, and enqueued
in the new one.  This would properly update the migration state.
Likewise, if it had its mask changed the set_cpus_allowed_rt() would
update the migration state.

Regards,
-Greg
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[PATCH 0/3] RT: balance rt tasks enhancements v6, Gregory Haskins, (Thu Oct 25, 7:46 am)
[PATCH 1/3] RT: cleanup some push-rt logic, Gregory Haskins, (Thu Oct 25, 7:46 am)
[PATCH 3/3] RT: CPU priority management, Gregory Haskins, (Thu Oct 25, 7:46 am)
Re: [PATCH 3/3] RT: CPU priority management, Steven Rostedt, (Thu Oct 25, 8:27 am)
Re: [PATCH 3/3] RT: CPU priority management, Gregory Haskins, (Thu Oct 25, 10:26 am)
Re: [PATCH 3/3] RT: CPU priority management, Steven Rostedt, (Thu Oct 25, 10:36 am)
Re: [PATCH 3/3] RT: CPU priority management, Gregory Haskins, (Thu Oct 25, 10:55 am)
Re: [PATCH 2/3] RT: Cache cpus_allowed weight for optimizi ..., Gregory Haskins, (Thu Oct 25, 11:51 am)