[lkml]   [2010]   [Nov]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC/RFT PATCH v3] sched: automated per tty task groups
    On Fri, 19.11.10 14:12, Ben Gamari ( wrote:

    > On Fri, 19 Nov 2010 09:51:14 -0800, Linus Torvalds <> 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 Poettering - Red Hat, Inc.

     \ /
      Last update: 2010-11-20 02:15    [W:0.027 / U:17.300 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site