linux-kernel - Re: [PATCH, v8 3/3] cgroups: introduce timer slack controller

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] [day] [month] [year] [list]

Message-Id: <20110307151932.4d73c3ff.akpm@linux-foundation.org>
Date:	Mon, 7 Mar 2011 15:19:32 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	"Kirill A. Shutsemov" <kirill@...temov.name>
Cc:	Paul Menage <menage@...gle.com>, Li Zefan <lizf@...fujitsu.com>,
	containers@...ts.linux-foundation.org,
	jacob.jun.pan@...ux.intel.com,
	Arjan van de Ven <arjan@...ux.intel.com>,
	linux-kernel@...r.kernel.org, Matt Helsley <matthltc@...ibm.com>,
	linux-api@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH, v8 3/3] cgroups: introduce timer slack controller

On Thu,  3 Mar 2011 16:19:07 +0200
"Kirill A. Shutsemov" <kirill@...temov.name> wrote:

> --- /dev/null
> +++ b/Documentation/cgroups/timer_slack.txt
> @@ -0,0 +1,64 @@
> +Timer Slack Controller
> +=====================
> +
> +Overview
> +--------
> +
> +Every task_struct has timer_slack_ns value. This value uses to round up
> +poll() and select() timeout values. This feature can be useful in
> +mobile environment where combined wakeups are desired.
> +
> +cgroup subsys "timer_slack" implements timer slack controller. It
> +provides a way to set minimal timer slack value for a group of tasks.
> +If a task belongs to a cgroup with minimal timer slack value higher than
> +task's value, cgroup's value will be applied.

All I'm seeing here is a bunch of code, but no reason has been provided
for merging any of it.

Why do we need a cgroup for this as opposed to (say) inheritance over
fork(), or a system-wide knob, or a per-process/threadgroup knob, or
just leaving the existing code as-is?  Presumably you felt that a
cgroup approach is better for manageability, but you didn't tell us
about this and you didn't explore alternative ways of solving the
problem-which-you-didn't-describe.


Carefully describing the proposed feature and the overall value which
it brings does help to grease the wheels and is worth spending some
time over, please.  Don't expect the entire audience to be mind-readers!
--
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/