lkml.org 
[lkml]   [2010]   [Nov]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC/RFT PATCH v3] sched: automated per tty task groups
    Samuel Thibault, le Fri 19 Nov 2010 01:02:04 +0100, a écrit :
    > Linus Torvalds, le Thu 18 Nov 2010 15:51:35 -0800, a écrit :
    > > On Thu, Nov 18, 2010 at 3:43 PM, Samuel Thibault
    > > <samuel.thibault@ens-lyon.org> wrote:
    > > >
    > > > What overhead? The implementation of cgroups is actually already
    > > > hierarchical.
    > >
    > > Well, at least the actual group creation overhead.
    > >
    > > If it's a "only at setsid()", that's a fairly rare thing (although I
    > > think somebody might want to run something like the AIM7 benchmark - I
    > > have this memory of it doing lots of tty tests).
    > >
    > > Or if it's only at "user launches new program from window manager",
    > > that's rare too.
    > >
    > > But if you do it per process group, now you're doing one for each
    > > command invocation in a shell, for example.
    >
    > Well, if it's from an interactive shell, it's not really a problem :)
    >
    > But when it's from a script it can become one, yes. But are cgroups so
    > expensive?
    >
    > > If you're doing things per thread, you've already lost.
    >
    > Not per thread, per process, i.e. put threads of the same process in the
    > same cgroup. Again, I would have thought that creating a cgroup is very
    > lightweight in front of a fork(). If not, maybe we are just looking for
    > another, more lightweight container information that the scheduler would
    > use [1], and keep more heavyweight containers for the non-automatic
    > creation way.
    >
    > > Also, remember the goal: it was never about some theoretical end
    > > result. It's all about a simple heuristic that makes things work
    > > better. Trying to do that "perfectly" totally and utterly misses the
    > > whole point.
    >
    > Sure. Using sid should already be quite good, but including the uid
    > information as well should be easily even better.

    Also note that having a hierarchical process structure should permit to
    make things globally more efficient: avoid putting e.g. your cpp, cc1,
    and asm processes at three corners of your 4-socket NUMA machine :)

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

    \
     
     \ /
      Last update: 2010-11-19 01:09    [W:4.501 / U:1.124 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site