lkml.org 
[lkml]   [2010]   [Nov]   [19]   [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
    On Fri, 19.11.10 14:12, Ben Gamari (bgamari.foss@gmail.com) wrote:

    >
    > On Fri, 19 Nov 2010 09:51:14 -0800, Linus Torvalds <torvalds@linux-foundation.org> wrote:
    > > And the user level approach? I think it's fine too. If you run systemd
    > > for other reasons (or if the gnome people add it to the task launcher
    > > or whatever), doing it there isn't wrong. I personally think it's
    > > somewhat disgusting to have a user-level callback with processes etc
    > > just to clean up a group, but whatever. As long as it's not common,
    > > who cares?
    > >
    > On that note, is there a good reason why the notify_on_release interface
    > works the way it does? Wouldn't it be simpler if the cgroup simply
    > provided a file on which a process (e.g. systemd) could block?

    The notify_on_release interface is awful indeed. Feels like the old
    hotplug interface where each module request by the kernel caused a
    hotplug script to be spawned by the kernel.

    However, I am not sure I like the idea of having pollable files like that,
    because in the systemd case I am very much interested in getting
    recursive notifications, i.e. I want to register once for getting
    notifications for a full subtree instead of having to register for each
    cgroup individually.

    My personal favourite solution would be to get a netlink msg when a
    cgroup runs empty. That way multiple programs could listen to the events
    at the same time, and we'd have an easy way to subscribe to a whole
    hierarchy of groups.

    Lennart

    --
    Lennart Poettering - Red Hat, Inc.


    \
     
     \ /
      Last update: 2010-11-20 02:15    [W:2.804 / U:0.028 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site