> 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.
>
