On Thu, 11 Nov 2010 08:26:40 MST, Mike Galbraith said:

> Implementation: each task struct contains an inherited pointer to a refcounted
> autogroup struct containing a task group pointer, the default for all tasks
> pointing to the init_task_group.  When a task calls __proc_set_tty(), the
> task's reference to the default group is dropped, a new task group is created,
> and the task is moved out of the old group and into the new.  Children thereafter
> inherit this task group, and increase it's refcount.  Calls to __tty_hangup()
> and proc_clear_tty() move the caller back to the init_task_group, and possibly
> destroy the task group.  On exit, reference to the current task group is dropped,
> and the task group is potentially destroyed.  At runqueue selection time, iff
> a task has no cgroup assignment, it's current autogroup is used.

So the set of all tasks that never call proc_set_tty() ends up in the same one
big default group, correct?  Do we have any provisions for making sure that if
a user has 8 or 10 windows open doing heavy work, the default group (with a lot
of important daemons/etc in it) doesn't get starved with only a 1/10th share of
the CPU? Or am I missing something here?

> +extern void sched_autogroup_detatch(struct task_struct *p);

sched_autogroup_detach() instead?