Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755498Ab0FDKEN (ORCPT ); Fri, 4 Jun 2010 06:04:13 -0400 Received: from mx2.mail.elte.hu ([157.181.151.9]:56544 "EHLO mx2.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753933Ab0FDKEL (ORCPT ); Fri, 4 Jun 2010 06:04:11 -0400 Date: Fri, 4 Jun 2010 12:03:06 +0200 From: Ingo Molnar To: Peter Zijlstra Cc: tytso@mit.edu, Brian Swetland , Neil Brown , Arve Hj?nnev?g , Thomas Gleixner , "Rafael J. Wysocki" , Alan Stern , Felipe Balbi , LKML , Florian Mickler , Linux OMAP Mailing List , Linux PM , Alan Cox , James Bottomley , Linus Torvalds , Kevin Hilman , "H. Peter Anvin" , Arjan van de Ven Subject: Re: suspend blockers & Android integration Message-ID: <20100604100306.GB3324@elte.hu> References: <20100603193045.GA7188@elte.hu> <20100603231153.GA11302@elte.hu> <20100603232302.GA16184@elte.hu> <1275644619.27810.39462.camel@twins> <1275645245.27810.39493.camel@twins> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1275645245.27810.39493.camel@twins> User-Agent: Mutt/1.5.20 (2009-08-17) X-ELTE-SpamScore: -2.0 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=-2.0 required=5.9 tests=BAYES_00 autolearn=no SpamAssassin version=3.2.5 -2.0 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1289 Lines: 31 * Peter Zijlstra wrote: > On Fri, 2010-06-04 at 11:43 +0200, Peter Zijlstra wrote: > > I still believe containment is a cgroup problem. The freeze/snapshot/resume > > container folks seem to face many of the same problems. Including the > > pending timer one I suspect. Lets solve it there. > > While talking to Thomas about this, we'd probably need a CLOCK_MONOTONIC > namespace to pull this off, so that resumed apps don't see the jump in > absolute time. > > This would also help with locating the relevant timers, since they'd be on > the related timer base. Ok - this looks workable, and looks technically isolated that can be pursued as a separate module of this whole topic. > The only 'interesting' issue I can see here is that if you create 1000 > CLOCK_MONOTONIC namepaces, we'd need to have a tree of trees in order to > efficiently find the leftmost timer. Realistically Android userspace would create just a single such namespace for all the untrusted/unknown/uncontrolled apps, right? Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/