From: Thomas Gleixner <tglx@linutronix.de>
To: Jeff Layton <jlayton@kernel.org>,
John Stultz <jstultz@google.com>, Stephen Boyd <sboyd@kernel.org>
Cc: Vadim Fedorenko <vadim.fedorenko@linux.dev>,
linux-kernel@vger.kernel.org, Jeff Layton <jlayton@kernel.org>
Subject: Re: [PATCH RFC] timekeeping: don't use seqcount loop in ktime_mono_to_any on 64-bit arch
Date: Tue, 10 Sep 2024 13:58:58 +0200 [thread overview]
Message-ID: <878qvzbtz1.ffs@tglx> (raw)
In-Reply-To: <20240910-mgtime-v1-1-35fb64bd0af5@kernel.org>
On Tue, Sep 10 2024 at 07:17, Jeff Layton wrote:
Please describe functions with foo() and not foo. Also please refrain
from using abbreviations. The 'arch' above is not really useful.
64-bit systems perhaps?
> ktime_mono_to_any only fetches the offset inside the loop. This is a
> single word on 64-bit arch, and seqcount_read_begin implies a full SMP
> barrier. While we do want to use the latest offset value available, a
We do nothing.
> full seqcount loop is overkill on 64-bit, where there is no possibility
> of torn reads. Just do a READ_ONCE for that and don't bother with the
> seqcount.
don't bother is not really a technical term.
https://www.kernel.org/doc/html/latest/process/maintainer-tip.html#changelog
> +#if BITS_PER_LONG == 64
> +ktime_t ktime_mono_to_any(ktime_t tmono, enum tk_offsets offs)
> +{
> + ktime_t *offset = offsets[offs];
> +
> + return ktime_add(tmono, READ_ONCE(*offset));
Where is the corresponing WRITE_ONCE()?
> +}
> +EXPORT_SYMBOL_GPL(ktime_mono_to_any);
> +#else /* BITS_PER_LONG == 64 */
> EXPORT_SYMBOL_GPL(ktime_mono_to_any);
> +#endif /* BITS_PER_LONG == 64 */
Why do we need this export twice?
Thanks,
tglx
next prev parent reply other threads:[~2024-09-10 11:59 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-10 11:17 [PATCH RFC] timekeeping: don't use seqcount loop in ktime_mono_to_any on 64-bit arch Jeff Layton
2024-09-10 11:58 ` Thomas Gleixner [this message]
2024-09-10 12:32 ` Jeff Layton
2024-09-10 15:39 ` 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=878qvzbtz1.ffs@tglx \
--to=tglx@linutronix.de \
--cc=jlayton@kernel.org \
--cc=jstultz@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sboyd@kernel.org \
--cc=vadim.fedorenko@linux.dev \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.