Re: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]

Ingo Molnar
2007-04-18T21:48:43Z

* Davide Libenzi <davidel@xmailserver.org> wrote:

> I think Ingo's idea of a new sched_group to contain the generic
> parameters needed for the "key" calculation, works better than adding
> more fields to existing strctures (that would, of course, host
> pointers to it). Otherwise I can already the the struct_signal being
> the target for other unrelated fields :)

yeah. Another detail is that for global containers like uids, the
statistics will have to be percpu_alloc()-ed, both for correctness
(runqueues are per CPU) and for performance.

That's one reason why i dont think it's necessarily a good idea to
group-schedule threads, we dont really want to do a per thread group
percpu_alloc().

In fact for threads the _reverse_ problem exists, threaded apps tend to
_strive_ for more performance - hence their desperation of using the
threaded programming model to begin with ;) (just think of media
playback apps which are typically multithreaded)

I dont think threads are all that different. Also, the
resource-conserving act of using CLONE_VM to share the VM (and to use a
different programming environment like Java) should not be 'punished' by
forcing the thread group to be accounted as a single, shared entity
against other 'fat' tasks.

so my current impression is that we want per UID accounting to solve the
X problem, the kernel threads problem and the many-users problem, but
i'd not want to do it for threads just yet because for them there's not
really any apparent problem to be solved.

Ingo