From: John Stultz <john.stultz@linaro.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: David Gibson <david@gibson.dropbear.id.au>,
lkml <linux-kernel@vger.kernel.org>,
Liav Rehana <liavr@mellanox.com>,
Chris Metcalf <cmetcalf@mellanox.com>,
Richard Cochran <richardcochran@gmail.com>,
Ingo Molnar <mingo@kernel.org>,
Prarit Bhargava <prarit@redhat.com>,
Laurent Vivier <lvivier@redhat.com>,
"Christopher S . Hall" <christopher.s.hall@intel.com>,
"4.6+" <stable@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH] timekeeping: Change type of nsec variable to unsigned in its calculation.
Date: Thu, 1 Dec 2016 13:19:00 -0800 [thread overview]
Message-ID: <CALAqxLXg2i6uiWcq21LK-ZsPvtugbuJa7Y8U0upXczS_o9aZOQ@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1612012127260.3666@nanos>
On Thu, Dec 1, 2016 at 12:46 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
> On Thu, 1 Dec 2016, John Stultz wrote:
>> I would also suggest:
>> 3) If the systems are halted for longer then the timekeeping core
>> expects, the system will "miss" or "lose" some portion of that halted
>> time, but otherwise the system will function properly. Which is the
>> result with this patch.
>
> Wrong. This is not the result with this patch.
>
> If the time advances enough to overflow the unsigned mult, which is
> entirely possible as it takes just twice the time of the negative overflow,
> then time will go backwards again and that's not 'miss' or 'lose', that's
> just broken.
Eh? If you overflow the 64bits on the mult, the shift (which is likely
large if you're actually hitting the overflow) brings the value back
down to a smaller value. Time doesn't go backwards, its just smaller
then it ought to be (since the high bits were lost).
> If we want to prevent that, then we either have to clamp the delta value,
> which is the worst choice or use 128bit math to avoid the overflow.
I'm not convinced yet either of these approaches are really needed.
>> I'm not sure if its really worth trying to recover that time or be
>> perfect in those situations. Especially since on narrow clocksources
>> you'll have the same result.
>
> We can deal with the 64bit overflow at least for wide clocksources which
> all virtualizaton infected architectures provide in a sane way.
Another approach would be to push back on the virtualization
environments to step in and virtualize a solution if they've idled a
host for too long. They could do like the old tick-based
virtualization environments used to and trigger a few timer interrupts
while slowly removing a fake negative clocksource offset to allow time
to catch up more normally after a long stall.
Or they could require clocksources that have smaller shift values to
allow longer idle periods.
> For bare metal systems with narrow clocksources the whole issue is non
> existant we can make the 128bit math depend on both a config switch and a
> static key, so bare metal will not have to take the burden.
Bare metal machines also sometimes run virtualization. I'm not sure
the two are usefully exclusive.
thanks
-john
next prev parent reply other threads:[~2016-12-01 21:19 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-19 4:53 [PATCH] timekeeping: Change type of nsec variable to unsigned in its calculation John Stultz
2016-11-28 22:50 ` John Stultz
2016-11-29 14:22 ` Thomas Gleixner
2016-11-29 23:57 ` David Gibson
2016-11-30 23:21 ` Thomas Gleixner
2016-12-01 2:12 ` David Gibson
2016-12-01 11:59 ` Thomas Gleixner
2016-12-01 20:23 ` John Stultz
2016-12-01 20:46 ` Thomas Gleixner
2016-12-01 21:19 ` John Stultz [this message]
2016-12-01 22:44 ` Thomas Gleixner
2016-12-01 23:03 ` John Stultz
2016-12-01 23:08 ` Thomas Gleixner
2016-12-01 23:32 ` David Gibson
2016-12-02 8:36 ` Thomas Gleixner
2016-12-03 0:33 ` David Gibson
-- strict thread matches above, loose matches on Subject: below --
2016-09-26 6:13 Liav Rehana
2016-09-26 5:45 Liav Rehana
2016-09-26 6:02 ` John Stultz
2016-09-27 0:01 ` Thomas Gleixner
2016-09-27 5:10 ` Liav Rehana
2016-09-27 14:18 ` Thomas Gleixner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CALAqxLXg2i6uiWcq21LK-ZsPvtugbuJa7Y8U0upXczS_o9aZOQ@mail.gmail.com \
--to=john.stultz@linaro.org \
--cc=christopher.s.hall@intel.com \
--cc=cmetcalf@mellanox.com \
--cc=david@gibson.dropbear.id.au \
--cc=liavr@mellanox.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lvivier@redhat.com \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=prarit@redhat.com \
--cc=richardcochran@gmail.com \
--cc=stable@vger.kernel.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).