From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933698AbbA2DeO (ORCPT ); Wed, 28 Jan 2015 22:34:14 -0500 Received: from mail-yk0-f171.google.com ([209.85.160.171]:53422 "EHLO mail-yk0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757205AbbA2DeK (ORCPT ); Wed, 28 Jan 2015 22:34:10 -0500 MIME-Version: 1.0 In-Reply-To: References: <1421928077-4698-1-git-send-email-pang.xunlei@linaro.org> <1421928077-4698-3-git-send-email-pang.xunlei@linaro.org> Date: Thu, 29 Jan 2015 00:00:07 +0800 Message-ID: Subject: Re: [PATCH v2 3/3] time: clocksource: Add a comment to CLOCK_SOURCE_SUSPEND_NONSTOP From: Xunlei Pang To: Thomas Gleixner Cc: lkml , "rtc-linux@googlegroups.com" , Alessandro Zummo , John Stultz , Arnd Bergmann Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Thomas, On 25 January 2015 at 01:07, Thomas Gleixner wrote: > On Sat, 24 Jan 2015, Xunlei Pang wrote: > >> Before this, I tried to add some code to catch such problem at the >> time of registering the clocksource, like using the >> CLOCKSOURCE_MASK(), for example 64bit counter will never wrap for >> us. But there may be other values like CLOCKSOURCE_MASK(56), I just >> can't figure out exactly how to do this judge. > > I don't think there is a good way to do so. Registration time is the > wrong place anyway because the problem depends on: > > - The width of the counter > - The frequency of the counter > > The frequency of the counter might even change after registration. Now > add the unknown duration of the suspend to the picture and you're > completely lost. > > All we can do is provide information about the actual wraparound time, > if the CLOCK_SOURCE_SUSPEND_NONSTOP flag is set and the wraparound > time is less than some reasonable margin. > Yes, we can only deal with it approximately. How about this? 1) Add a new member about reference wraparound time(max system suspend period allowed) to struct clocksource. In __clocksource_updatefreq_scale(), we can use "sec" which already applys 12.5% margin as its value. 2) Add a new tuneable sysctl threshold with a default time period value(for example, 365 days) We can also printk its value when booting or changing its value to notice people about this. 3) then, in timekeeping_resume(), we can compare the reference wraparound of the nonstop clocksource with the sysctl threshold to decide if it is dependable to use. Thanks, Xunlei > > > >