[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4E9BBB6D.4050004@linux.intel.com>
Date: Sun, 16 Oct 2011 22:21:49 -0700
From: Arjan van de Ven <arjan@...ux.intel.com>
To: Matthew Garrett <mjg@...hat.com>
CC: Lennart Poettering <mzxreary@...inter.de>,
Peter Zijlstra <peterz@...radead.org>,
Andrew Morton <akpm@...ux-foundation.org>,
"Kirill A. Shutemov" <kirill@...temov.name>,
Paul Menage <menage@...gle.com>,
Li Zefan <lizf@...fujitsu.com>,
Thomas Gleixner <tglx@...utronix.de>,
containers@...ts.linux-foundation.org,
jacob.jun.pan@...ux.intel.com, linux-kernel@...r.kernel.org,
Matt Helsley <matthltc@...ibm.com>, linux-api@...r.kernel.org,
Kay Sievers <kay.sievers@...y.org>, harald@...hat.com,
david@...ar.dk, greg@...ah.com
Subject: Re: [PATCH, v10 3/3] cgroups: introduce timer slack controller
On 10/16/2011 8:22 PM, Matthew Garrett wrote:
> On Mon, Oct 17, 2011 at 03:39:21AM +0200, Lennart Poettering wrote:
>> On Sat, 15.10.11 21:11, Peter Zijlstra (peterz@...radead.org) wrote:
>>> I would argue this is an excellent reason not to merge this. This really
>>> is in the camp of lets paper over shitty userspace instead of fix it.
>>>
>>> Such a scheme takes away the immediate need to fix crap and therefore
>>> crap will not get fixed. Why not focus on creating tools (I think
>>> powertop really already does everything you need) and track down WTF
>>> apps are firing so many timers when the screen if off.
>> Well, maybe that works in fantasy land. In real life however there's
>> stuff like closed source crap, and all kinds of other things you cannot
>> fix. In a world where everybody wants "apps" (i.e. 3rd party code
>> running with limited privileges) your chance to fix every bit of code is
>> gone.
> I agree. We can't assume perfect software, and I don't think *requiring*
> the duplication of this functionality in every single session
> application is sensible. We want to be able to shut down timer based
> code when the session is idle. We could do this by exposing the slack in
> /proc. We could do this by modifying every piece of code to listen for
> session idle events and (independently) enact session-wide policy. Or we
> could just accept that it's a problem that maps onto what people are
> already using cgroups for and implement it in the same way.
and..it's not like we let the bad guys go free.
We actually seriously hurt their behavior while we throttle their timers
here.
--
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