Re: [PATCH RFC] timekeeping: don't use seqcount loop in ktime_mono_to_any on 64-bit arch

[Jeff Layton <jlayton@kernel.org>]

On Tue, 2024-09-10 at 13:58 +0200, Thomas Gleixner wrote:
> 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?
> 

Thanks, will fix.

> > 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.
> 

I assume you mean "we do not". Fair enough. I misinterpreted the
purpose of the seqcount loop then.

> > 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
> 

Thanks, fixed.

> > +#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()?
> 

I'll just make it do a simple fetch without READ_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?
> 

We don't (obviously). I wasn't sure whether it was preferred to put it
inside the #ifdef.

Now that I look though, the resulting helper is very simple. Would it
be better to make this a static inline instead of an exported symbol?

----------------8<----------------
ktime_t ktime_mono_to_any(ktime_t tmono, enum tk_offsets offs)
{
        ktime_t *offset = offsets[offs];

        return ktime_add(tmono, *offset);
}
----------------8<----------------

-- 
Jeff Layton <jlayton@kernel.org>