From mboxrd@z Thu Jan 1 00:00:00 1970 From: john stultz Subject: Re: Timekeeping issue on aggressive suspend/resume Date: Thu, 10 Jun 2010 12:52:48 -0700 Message-ID: <1276199568.16089.35.camel@work-vm> References: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Suresh Rajashekara Cc: Thomas Gleixner , linux-omap@vger.kernel.org, LKML , linux-pm@lists.linux-foundation.org List-Id: linux-omap@vger.kernel.org On Wed, 2010-06-09 at 23:34 -0700, Suresh Rajashekara wrote: > On Wed, Jun 9, 2010 at 1:22 PM, Thomas Gleixner wrote: > > Though we could change that conditionally - the default would still be > > the freeze of jiffies and CLOCK_MONOTONIC for historical compability. > > If I were to change it only for our implementation, and make all the > user space timers use CLOCK_REALTIME, then could you please point me > in a direction as to what part of the kernel I should be touching to > make that change? I think Thomas was suggesting that you consider creating a option for where CLOCK_MONOTONIC included total_sleep_time. In that case the *hack* (and this is a hack, we'll need some more thoughtful discussion before anything like it could make it upstream) would be in timekeeping_resume() to comment out the lines that update wall_to_monotonic and total_sleep_time. It would be interesting to hear if that hack works for you, and we can try to come up with a better way to think about how to accommodate both views of how to account time over suspend. Thomas, might this call for a new posix clock_id, CLOCK_BOOTTIME (ie: CLOCK_MONOTONIC + total_sleep_time) or something that userland could use to set timers on? thanks -john