[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110304122035.GB14933@shutemov.name>
Date: Fri, 4 Mar 2011 14:20:35 +0200
From: "Kirill A. Shutemov" <kirill@...temov.name>
To: Arnd Bergmann <arnd@...db.de>
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>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-api@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH, v8 1/3] hrtimer: introduce effective timer slack
On Thu, Mar 03, 2011 at 05:32:28PM +0100, Arnd Bergmann wrote:
> On Thursday 03 March 2011, Kirill A. Shutsemov wrote:
> > task_get_effective_timer_slack() returns timer slack value to be used
> > to configure per-task timers. It can be equal or higher than task's
> > timer slack value.
> >
> > For now task_get_effective_timer_slack() returns timer_slack_ns of the
> > task. Timer slack cgroup controller will implement a bit more
> > sophisticated logic.
>
> Some time ago, there was a discussion about a method for automatically
> determining timer slack values, and I think nobody ever implemented it.
>
> The idea was to penalize tasks that have timers expiring a lot, typically
> a sign of programs that were not written with power consumption in mind.
>
> I think that could be nicely combined with your patch. Instead of setting
> the effective timer slack for the entire control group, you could
> set a target value that is applied only to tasks that have their timers
> expire frequently. When a timer expires for a task, you increase the
> effective slack up to the maximum, and when you set up a timer, you
> decrease it again. The amount by which the effective slack gets changed
> can depend on how long ago the last timer expired.
>
> Does this make sense to you?
Hm.. I think we can add this kind of functionality to timer slack cgroup
as a policy/stratagy later. I want to integrate basic functionality to
kernel first.
--
Kirill A. Shutemov
--
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