* Davide Libenzi <[EMAIL PROTECTED]> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
