linux-kernel - Re: [PATCH] clocksource: register persistent clock for arm arch

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <533C525C.3070909@codeaurora.org>
Date:	Wed, 02 Apr 2014 11:09:32 -0700
From:	Stephen Boyd <sboyd@...eaurora.org>
To:	Lei Wen <leiwen@...vell.com>,
	Daniel Lezcano <daniel.lezcano@...aro.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] clocksource: register persistent clock for arm arch_timer

On 04/02/14 04:02, Lei Wen wrote:
> Since arm's arch_timer's counter would keep accumulated even in the
> low power mode, including suspend state, it is very suitable to be
> the persistent clock instead of RTC.
>
> While read_persistent_clock calling place shall be rare, like only
> suspend/resume place? So we shall don't care for its performance
> very much, so use direclty divided by frequency should be accepted
> for this reason. Actually archtimer's counter read performance already
> be very good, since it is directly access from core's bus, not from
> soc, so this is another reason why we choose use divide here.
>
> Final reason for why we don't use multi+shift way is for we may not
> call read_persistent_clock for long time, like system long time
> not enter into suspend, so that the accumulated cycle difference value
> may larger than we used for calculate the multi+shift, thus precise
> would be highly affected in such corner case.
>
> Signed-off-by: Lei Wen <leiwen@...vell.com>
> ---
>
> I am not sure whether it is good to add something like
> generic_persistent_clock_read in the new added kernel/time/sched_clock.c?
> Since from arch timer's perspective, all it need to do is to pick
> the suspend period from the place where sched_clock being stopped/restarted.
>
> Any idea for make the persistent clock reading as one generic function,
> like current sched_clock do?

Why do we need this? Don't we put the CLOCK_SOURCE_SUSPEND_NONSTOP flag
on the arm_arch_timer clocksource to handle this? The only reason I can
think of would be that you're calling read_persistent_clock() from
somewhere else besides the timekeeping core. If that's why, please use
the time functionality like ktime_get_boottime() or
get_monotonic_boottime().

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

--
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/