lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1289864780.14719.172.camel@maggy.simson.net>
Date:	Mon, 15 Nov 2010 16:46:20 -0700
From:	Mike Galbraith <efault@....de>
To:	Valdis.Kletnieks@...edu
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Oleg Nesterov <oleg@...hat.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	Ingo Molnar <mingo@...e.hu>,
	LKML <linux-kernel@...r.kernel.org>,
	Markus Trippelsdorf <markus@...ppelsdorf.de>
Subject: Re: [RFC/RFT PATCH v3] sched: automated per tty task groups

On Mon, 2010-11-15 at 17:41 -0500, Valdis.Kletnieks@...edu 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ