From: Pavel Tatashin <pasha.tatashin@soleen.com>
To: Marc Zyngier <marc.zyngier@arm.com>
Cc: catalin.marinas@arm.com, Will Deacon <will.deacon@arm.com>,
Andrew Morton <akpm@linux-foundation.org>,
rppt@linux.vnet.ibm.com, Michal Hocko <mhocko@suse.com>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
andrew.murray@arm.com, james.morse@arm.com, sboyd@kernel.org,
linux-arm-kernel@lists.infradead.org,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 3/3] arm64: Early boot time stamps
Date: Thu, 3 Jan 2019 14:58:25 -0500 [thread overview]
Message-ID: <CA+CK2bA_006YGu3dtJM24pN1ZGgcJZnF2oEeWKkq3QBrcCbB6Q@mail.gmail.com> (raw)
In-Reply-To: <9fe670d4-d799-c05f-297e-437eda1d2072@arm.com>
> I still think this approach is flawed. You provide the kernel with a
> potentially broken sched_clock that may jump back and forth until the
> workaround kicks in. Nobody expects this.
>
> Instead, I'd suggest you allow for a something other than local_clock()
> to be used for the time stamping until a properly working sched_clock
> gets registered.
>
> This way, you'll only impact the timestamps when running on a broken system.
I think, given that on other platforms sched_clock() is already used
early, it is not a good idea to invent a different clock just for time
stamps.
We could limit arm64 approach only for chips where cntvct_el0 is
working: i.e. frequency is known, and the clock is stable, meaning
cannot go backward. Perhaps we would start early clock a little later,
but at least it will be available for the sane chips. The only
question, where during boot time this is known.
Another approach is to modify sched_clock() in
kernel/time/sched_clock.c to never return backward value during boot.
1. Rename current implementation of sched_clock() to sched_clock_raw()
2. New sched_clock() would look like this:
u64 sched_clock(void)
{
if (static_branch(early_unstable_clock))
return sched_clock_unstable();
else
return sched_clock_raw();
}
3. sched_clock_unstable() would look like this:
u64 sched_clock_unstable(void)
{
again:
static u64 old_clock;
u64 new_clock = sched_clock_raw();
static u64 old_clock_read = READ_ONCE(old_clock);
/* It is ok if time does not progress, but don't allow to go backward */
if (new_clock < old_clock_read)
return old_clock_read;
/* update the old_clock value */
if (cmpxchg64(&old_clock, old_clock_read, new_clock) != old_clock_read)
goto again;
return new_clock;
}
Pasha
next prev parent reply other threads:[~2019-01-03 19:58 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-26 16:45 [PATCH v3 0/3] Early boot time stamps for arm64 Pavel Tatashin
2018-12-26 16:45 ` [PATCH v3 1/3] arm_arch_timer: add macro for timer nbits Pavel Tatashin
2018-12-26 16:45 ` [PATCH v3 2/3] arm64: vdso: Use ARCH_TIMER_NBITS to calculate mask Pavel Tatashin
2018-12-26 16:45 ` [PATCH v3 3/3] arm64: Early boot time stamps Pavel Tatashin
2019-01-03 10:51 ` Marc Zyngier
2019-01-03 19:58 ` Pavel Tatashin [this message]
2019-01-04 15:39 ` Marc Zyngier
2019-01-04 16:23 ` Pavel Tatashin
2019-01-04 16:49 ` Marc Zyngier
2019-01-04 20:54 ` Pavel Tatashin
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=CA+CK2bA_006YGu3dtJM24pN1ZGgcJZnF2oEeWKkq3QBrcCbB6Q@mail.gmail.com \
--to=pasha.tatashin@soleen.com \
--cc=akpm@linux-foundation.org \
--cc=andrew.murray@arm.com \
--cc=ard.biesheuvel@linaro.org \
--cc=catalin.marinas@arm.com \
--cc=james.morse@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marc.zyngier@arm.com \
--cc=mhocko@suse.com \
--cc=rppt@linux.vnet.ibm.com \
--cc=sboyd@kernel.org \
--cc=will.deacon@arm.com \
/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).