RE: [PATCH v3] Added "Preserve Boot Time Support"

From	"Mirea, Bogdan-Stefan" <Bogdan-Stefan_Mirea@mentor.com>
Newsgroups	linux.kernel
Subject	RE: [PATCH v3] Added "Preserve Boot Time Support"
Date	2017-05-24 11:40 +0200
Message-ID	<tKAVQ-wS-25@gated-at.bofh.it> (permalink)
References	<tINaN-JU-9@gated-at.bofh.it> <tJGJX-4JY-9@gated-at.bofh.it> <tKko2-5cc-21@gated-at.bofh.it> <tKl0K-5Ft-21@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

On Tuesday, May 23, 2017 7:39 PM, Thomas Gleixner wrote:
> On Tue, 23 May 2017, Mirea, Bogdan-Stefan wrote:
> > On Monday, May 22, 2017 12:36 AM, Thomas Gleixner wrote:
> > > On Fri, 19 May 2017, Bogdan Mirea wrote:
> > > This adds a arch_timer specific command line option. Why is this
> > > arch_timer
> > > specific? So if any other platform wants to gain this feature then we
> > > end
> > > up copying that mess to every single timer implementation? Certainly
> > > NOT!
> > > Exactly nothing. settimeofday() modifies CLOCK_REALTIME and if the
> > > platform
> > > has an early accessible RTC, you hereby wreckaged wall_time. If the
> > > RTC
> > > readout comes later then CLOCK_REALTIME is overwritten. So what is
> > > this
> > > supposed to do?
> > >
> > > It has absolutely nothing to do with CLOCK_BOOTTIME. /proc/uptime is
> > > based
> > > on CLOCK_BOOTTIME, which is the CLOCK_MONOTONIC time since system
> > > boot. The
> > > difference between CLOCK_MONOTONIC and CLOCK_BOOTTIME is that
> > > CLOCK_MONOTONIC does not advance during suspend, but
> CLOCK_BOOTTIME
> > > takes
> > > the suspended time into account.
> > Thanks for feedback.
> > The idea of this patch was of a POC and this is why the code was
> > isolated in timer driver, which I agree is not a good idea for other
> > platforms to copy this since we can simply do all the things in
> > sched_clock_register() function guarded with
> CONFIG_BOOT_TIME_PRESERVE.
> > The patch was created for an internal project where no RTC was available
> > and no user-space apps were making any settimeofday(), and the use of
> > do_settimeofday() seemed safe. But yes, considering that the
> > CLOCK_REALTIME can be easily changed it should not be used here.
> 
> It does not matter at all whether you have a RTC or settimeofday() is used
> or not.
> 
> Again:
> 
> > > It has absolutely nothing to do with CLOCK_BOOTTIME. /proc/uptime is
> > > based on CLOCK_BOOTTIME, which is the CLOCK_MONOTONIC time since
> system
> > > boot. The difference between CLOCK_MONOTONIC and CLOCK_BOOTTIME
> is that
> > > CLOCK_MONOTONIC does not advance during suspend, but
> CLOCK_BOOTTIME
> > > takes the suspended time into account.
> 
> So using settimeofday() for any of what you want to do is bogus and
> useless.

Got it. Thanks!

I am thinking about using timekeeping_inject_sleeptime64(delta) hook to
add a delta time at boot to the CLOCK_BOOTTIME, but the problem that
arise here is that this hook is intended to be used on rtc_resume()
code (to add the time spent in suspend to CLOCK_BOOTTIME).
From my point of view this will do the trick even if the
CONFIG_BOOT_TIME_PRESERVE will then depend on PM_SLEEP && RTC_HCTOSYS
(needed by timekeeping_inject_sleeptime64 to work).
Do you think this is a good approach?

Regards,
Bogdan

Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

[PATCH v3] Added "Preserve Boot Time Support" Bogdan Mirea <Bogdan-Stefan_mirea@mentor.com> - 2017-05-19 12:20 +0200
  Re: [PATCH v3] Added "Preserve Boot Time Support" Thomas Gleixner <tglx@linutronix.de> - 2017-05-21 23:40 +0200
    RE: [PATCH v3] Added "Preserve Boot Time Support" "Mirea, Bogdan-Stefan" <Bogdan-Stefan_Mirea@mentor.com> - 2017-05-23 18:00 +0200
      RE: [PATCH v3] Added "Preserve Boot Time Support" Thomas Gleixner <tglx@linutronix.de> - 2017-05-23 18:40 +0200
        RE: [PATCH v3] Added "Preserve Boot Time Support" "Mirea, Bogdan-Stefan" <Bogdan-Stefan_Mirea@mentor.com> - 2017-05-24 11:40 +0200

csiph-web