Re: [RFC][PATCH 0/3] Refactoring sched_entity and sched_rt_entity.

[Lucas De Marchi]

Hi Dario

On Tue, Jan 4, 2011 at 13:55, Dario Faggioli <raistlin@xxxxxxxx> wrote:
> Hi everybody,
>
> After having heard Peter talking about it many times, I finally decided
> to give this thing a spin. It is basically the idea of putting the
> current sched_entity and sched_rt_entity together in an union, contained
> in a more general structure which hosts the common fields of the twos.
> For example, it came out here: http://lkml.org/lkml/2009/7/9/153
>
> Therefore, this patchset _DOES_NOT_ do that! :-O
>
> In fact, this is some preliminary refactoring which I think it's needed
> before union-ify the two data structure, and on which I would like to
> get some preliminary comments, before going ahead with the wrong
> approach.
>
> Basically, I renamed struct sched_entity to struct sched_cfs_entity and
> put it and sched_rt_entity inside a more general struct sched_entity...
> Is that clear? :-)
> The patches just cope with that. Yes, there's some work done by a patch
> and undone by the next one. I now it's annoying, and I'm sorry, but I
> did such for the sake of reviewability and for making each patch compile
> cleanly.
> As for the name of CFS's scheduling entities, sched_fair_entity would
> probably have been better, but it's longer, and "_cfs" is already
> present in many places, so I went for it... No big deal in changing
> that, apart from stay-within-80-characters-per-line issues! :-P
>
> They're not inside an union yet, because I'm not sure on how to treat
> the task group case. In fact, tasks can only have _just_one_ scheduling
> policy at a time, and thus, for example, they need the run_list _or_ the
> rb_node for queueing (if the task is RT or fair, respectively), which is
> perfect with respect to using an union.
> OTOH, groups are always considered both fair _and_ RT entities, for
> example they're always queued in _both_ an RT run_list and a fair
> rb-tree. So I can't put them in an union, because I need both at the
> same time!
> Suggestions on how to deal with that will be appreciated.
>

In fact I created the patchset but I didn't have time to finish,
polish, test and send. There are several corner cases that must be
treated that made me think if it was really worth the work.

In this repo you can find a greatly outdated branch that treats some
of the troubles you'll need to think about:

git://git.profusion.mobi/users/lucas/linux-2.6.git schedentity

And this was a rebase I did, but irc it was not working well:

git://git.profusion.mobi/users/lucas/linux-2.6.git schedentity-rebased




Lucas De Marchi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/