[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110210191117.GI16432@count0.beaverton.ibm.com>
Date: Thu, 10 Feb 2011 11:11:17 -0800
From: Matt Helsley <matthltc@...ibm.com>
To: Arjan van de Ven <arjan@...ux.intel.com>
Cc: Matt Helsley <matthltc@...ibm.com>, jacob.jun.pan@...ux.intel.com,
LKML <linux-kernel@...r.kernel.org>,
"Kirill A. Shutemov" <kirill@...temov.name>,
container cgroup <containers@...ts.linux-foundation.org>,
Li Zefan <lizf@...fujitsu.com>,
Paul Menage <menage@...gle.com>, akpm@...ux-foundation.org,
rdunlap@...otime.net, Cedric Le Goater <clg@...t.ibm.com>,
Wysocki Rafael Wysocki <rjw@...k.pl>
Subject: Re: [PATCH 1/1, v6] cgroup/freezer: add per freezer duty ratio
control
On Wed, Feb 09, 2011 at 07:06:15PM -0800, Arjan van de Ven wrote:
> On 2/9/2011 7:04 PM, Matt Helsley wrote:
> >On Tue, Feb 08, 2011 at 05:05:41PM -0800, jacob.jun.pan@...ux.intel.com wrote:
> >>From: Jacob Pan<jacob.jun.pan@...ux.intel.com>
> >>
> >>Freezer subsystem is used to manage batch jobs which can start
> >>stop at the same time. However, sometime it is desirable to let
> >>the kernel manage the freezer state automatically with a given
> >>duty ratio.
> >>For example, if we want to reduce the time that backgroup apps
> >>are allowed to run we can put them into a freezer subsystem and
> >>set the kernel to turn them THAWED/FROZEN at given duty ratio.
> >>
> >>This patch introduces two file nodes under cgroup
> >>freezer.duty_ratio_pct and freezer.period_sec
> >>
> >>Usage example: set period to be 5 seconds and frozen duty ratio 90%
> >>[root@...alhost aoa]# echo 90> freezer.duty_ratio_pct
> >>[root@...alhost aoa]# echo 5000> freezer.period_ms
> >I kept wondering how this was useful when we've got the "cpu" subsystem
> >because for some reason "duty cycle" made me think this was a scheduling
> >policy knob. In fact, I'm pretty sure it is -- it just happens to
> >sometimes reduce power consumption.
> >
> >Have you tried using the cpu cgroup subsystem's share to see if it can
> >have a similar effect?
>
> does the cpu cgroup system work on a 20 to 30 second time window?
I don't think so -- it works directly with the scheduler IIRC.
> the objective is to have the CPU idle, without wakeups, for that long...
> (to save power)
Hmm. Maybe these need some "scheduler slack" so that when they're
runnable they'll either run with other scheduled entities that are
keeping the cpu awake or wait until the slack runs out before doing
a wakeup. Then you can toss this in the cgroup timer slack subsystem
and rename it to the "wakeup slack" subsystem or something. That
will probably get you better race-to-idle behavior, avoid/reduce
latencies added by duty cycles, and avoid shoehorning into the cgroup
freezer subsystem. Of course it would require some scheduler hacking
which will probably be much more controversial than modifying a cgroup
subsystem :).
Cheers,
-Matt Helsley
--
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