From: Pasha Tatashin <pasha.tatashin@oracle.com>
To: Russell King - ARM Linux <linux@armlinux.org.uk>
Cc: schwidefsky@de.ibm.com, heiko.carstens@de.ibm.com,
john.stultz@linaro.org, sboyd@codeaurora.org, x86@kernel.org,
linux-kernel@vger.kernel.org, mingo@redhat.com,
peterz@infradead.org, tglx@linutronix.de, hpa@zytor.com,
douly.fnst@cn.fujitsu.com, Peter Zijlstra <peterz@infradead.org>,
Dou Liyang <douly.fnst@cn.fujitsu.com>
Subject: Re: [PATCH v6 1/4] sched/clock: interface to allow timestamps early in boot
Date: Wed, 27 Sep 2017 13:10:35 -0400 [thread overview]
Message-ID: <28c575e4-daa1-a959-e9a5-20f05033a6f0@oracle.com> (raw)
In-Reply-To: <20170927144506.GU20805@n2100.armlinux.org.uk>
Hi Russell,
This might be so for ARM, and in fact if you look at my SPARC
implementation, I simply made source clock initialize early, so regular
sched_clock() is used. As on SPARC, we use either %tick or %stick
registers with frequency determined via OpenFrimware. But, on x86 there
are dozen ways clock sources are setup, and some of them available quiet
late in boot because of various dependencies. So, my early clock
initialization for x86 (and expendable to other platforms with unstable
clocks) is to make it available when TSC is available, which is
determined by already existing kernel functionality in
simple_udelay_calibration().
My goal was not to introduce any regressions to the already complex (in
terms of number of branches and loads) sched_clock_cpu(), therefore I
added a new function and avoided any extra branches through out the life
of the system. I could mitigate some of that by using static branches,
but imo the current approach is better.
Pasha
next prev parent reply other threads:[~2017-09-27 17:11 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-30 18:03 [PATCH v6 0/4] Early boot time stamps for x86 Pavel Tatashin
2017-08-30 18:03 ` [PATCH v6 1/4] sched/clock: interface to allow timestamps early in boot Pavel Tatashin
2017-09-27 12:58 ` Peter Zijlstra
2017-09-27 13:10 ` Peter Zijlstra
2017-09-27 13:16 ` Pasha Tatashin
2017-09-27 13:52 ` Dou Liyang
2017-09-27 17:13 ` Pasha Tatashin
2017-09-27 18:05 ` Peter Zijlstra
2017-09-27 18:09 ` Peter Zijlstra
2017-09-28 10:03 ` Dou Liyang
2017-09-28 11:58 ` Peter Zijlstra
2017-09-28 12:12 ` Thomas Gleixner
2017-09-28 13:11 ` Pasha Tatashin
2017-09-29 15:00 ` Dou Liyang
2017-10-18 10:01 ` Dou Liyang
2017-10-18 13:38 ` Pavel Tatashin
2017-10-09 16:34 ` Pavel Tatashin
2017-10-18 21:01 ` Thomas Gleixner
2017-09-27 14:45 ` Russell King - ARM Linux
2017-09-27 17:10 ` Pasha Tatashin [this message]
2017-09-27 18:11 ` Peter Zijlstra
2017-08-30 18:03 ` [PATCH v6 2/4] time: sync read_boot_clock64() with persistent clock Pavel Tatashin
2017-08-30 18:03 ` [PATCH v6 3/4] x86/time: read_boot_clock64() implementation Pavel Tatashin
2017-08-30 18:03 ` [PATCH v6 4/4] x86/tsc: use tsc early Pavel Tatashin
[not found] ` <CALBSrqBKsojGGpe85GOg7jda-SJHLrR=pS-Pg-xa0SUg7j3OQA@mail.gmail.com>
2017-08-30 21:21 ` Fenghua Yu
2017-08-30 21:32 ` Pasha 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=28c575e4-daa1-a959-e9a5-20f05033a6f0@oracle.com \
--to=pasha.tatashin@oracle.com \
--cc=douly.fnst@cn.fujitsu.com \
--cc=heiko.carstens@de.ibm.com \
--cc=hpa@zytor.com \
--cc=john.stultz@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=sboyd@codeaurora.org \
--cc=schwidefsky@de.ibm.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/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
all inboxes | Powered by JetHome®