Re: [RFC/RFT PATCH v3] sched: automated per tty task groups

[Mike Galbraith]

On Mon, 2010-11-15 at 17:41 -0500, Valdis.Kletnieks@xxxxxx wrote:
> 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?

Yes, all tasks never having had a tty association are relegated to the
root task group, and no, there is no provision for the root task group
getting more than it's fair share of CPU.

The patch is only intended to (hopefully) better suit the general case
desktop.  One size has zero chance of fitting all ;-)

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

Hm, why?

	-Mike

	-Mike

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