linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@kernel.org>
To: Arnd Bergmann <arnd@arndb.de>, Geert Uytterhoeven <geert@linux-m68k.org>
Cc: linux-m68k@lists.linux-m68k.org, linux-kernel@vger.kernel.org,
	 linux-fsdevel@vger.kernel.org
Subject: Re: [jlayton:mgtime 5/13] inode.c:undefined reference to `__invalid_cmpxchg_size'
Date: Wed, 10 Jul 2024 07:57:15 -0400	[thread overview]
Message-ID: <0f701b07d9498b21929cbd86db1074cefc8d1332.camel@kernel.org> (raw)
In-Reply-To: <a3e1ebe1-79fa-438b-a196-3a1bff947bcd@app.fastmail.com>

On Wed, 2024-07-10 at 10:38 +0200, Arnd Bergmann wrote:
> On Tue, Jul 9, 2024, at 20:27, Jeff Layton wrote:
> > On Tue, 2024-07-09 at 19:06 +0200, Arnd Bergmann wrote:
> > > On Tue, Jul 9, 2024, at 17:27, Jeff Layton wrote:
> > > > On Tue, 2024-07-09 at 17:07 +0200, Arnd Bergmann wrote:
> > 
> > 
> > Yes, I had considered it on an earlier draft, but my attempt was pretty
> > laughable. You inspired me to take another look though...
> > 
> > If we go that route, what I think we'd want to do is add a new floor
> > value to the timekeeper and a couple of new functions:
> > 
> > ktime_get_coarse_floor - fetch the max of current coarse time and floor
> > ktime_get_fine_floor - fetch a fine-grained time and update the floor
> 
> I was thinking of keeping a name that is specific to the vfs
> usage instead of the ktime_get_* namespace. I'm sure the timekeeping
> maintainers will have an opinion on this though, one way or another.
> 

Fair enough.

> > The variety of different offsets inside the existing timekeeper code is
> > a bit bewildering, but I guess we'd want ktime_get_fine_floor to call
> > timekeeping_get_ns(&tk->tkr_mono) and keep the latest return cached.
> > When the coarse time is updated we'd zero out that cached floor value.
> 
> Why not update the cached value during the timekeeping update as well
> instead of setting it to zero? That way you can just always use the
> cached value for VFS and simplify the common code path for reading
> that value.
> 

You mean just update it to the coarse time on the update? That seems
like it would also work.

> > Updating that value in ktime_get_fine_floor will require locking or
> > (more likely) some sort of atomic op. timekeeping_get_ns returns u64
> > though, so I think we're still stuck needing to do a cmpxchg64.
> 
> Right, or atomic64_cmpxchg() to make it work on 32-bit.
> 

I think that's the catch. Without being able to move to cmpxchg32 for
the floor update, we're not buying much by bringing it into the
timekeeper. Is there some big benefit that I'm missing?

-- 
Jeff Layton <jlayton@kernel.org>

      reply	other threads:[~2024-07-10 11:57 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <202407091931.mztaeJHw-lkp@intel.com>
2024-07-09 11:58 ` Fwd: [jlayton:mgtime 5/13] inode.c:undefined reference to `__invalid_cmpxchg_size' Jeff Layton
2024-07-09 13:45   ` Geert Uytterhoeven
2024-07-09 14:16     ` Arnd Bergmann
2024-07-09 14:23       ` Jeff Layton
2024-07-09 15:07         ` Arnd Bergmann
2024-07-09 15:27           ` Jeff Layton
2024-07-09 17:06             ` Arnd Bergmann
2024-07-09 18:27               ` Jeff Layton
2024-07-10  8:38                 ` Arnd Bergmann
2024-07-10 11:57                   ` Jeff Layton [this message]

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=0f701b07d9498b21929cbd86db1074cefc8d1332.camel@kernel.org \
    --to=jlayton@kernel.org \
    --cc=arnd@arndb.de \
    --cc=geert@linux-m68k.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-m68k@lists.linux-m68k.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;
as well as URLs for NNTP newsgroup(s).