Re: [PATCH v4 2/9] fs: add infrastructure for multigrain inode i_m/ctime

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, May 21, 2023 at 01:11:31AM -0700, Paul E. McKenney wrote:
> On Sat, May 20, 2023 at 07:21:57PM -0700, Boqun Feng wrote:
> > [Cc Paul and Mark]
> > 
> > On Sat, May 20, 2023 at 04:06:43PM -0400, Theodore Ts'o wrote:
> > > On Thu, May 18, 2023 at 07:47:35AM -0400, Jeff Layton wrote:
> > > > Use the 31st bit of the ctime tv_nsec field to indicate that something
> > > > has queried the inode for the i_mtime or i_ctime. When this flag is set,
> > > > on the next timestamp update, the kernel can fetch a fine-grained
> > > > timestamp instead of the usual coarse-grained one.
> > > 
> > > TIL....  that atomic_long_fetch_or() and atomic_long_fetch_andnot()
> > > exist.  :-)
> > > 
> > > When I went looking for documentation about why they do or this
> > > particular usage pattern found in the patch, I didn't find any --- at
> > > least, certainly not in the Documentation in the kernel sources.  The
> > > closest that I fond was this LWN article written by Neil Brown from
> > > 2016:
> > > 
> > > 	https://lwn.net/Articles/698315/
> > > 
> > > ... and this only covered the use atomic_fetch_or(); I wasn't able to
> > > find anything discussing atomic_fetch_andnot().
> > > 
> > > It looks like Peter Zijlstra added some bare-bones documentation in
> > > 2017, in commit: 706eeb3e9c6f ("Documentation/locking/atomic: Add
> > > documents for new atomic_t APIs") so we do have Documentation that
> > > these functions *exist*, but there is nothing explaining what they do,
> > > or how they can be used (e.g., in this rather clever way to set and
> > > clear a flag in the high bits of the nsec field).
> > > 
> > > I know that it's best to report missing documentation in the form of a
> > > patch, but I fear I don't have the time or the expertise to really do
> > > this topic justice, so I'd just thought I'd just note this lack for
> > > now, and maybe in my copious spare time I'll try to get at least
> > > something that will no doubt contain errors, but might inspire some
> > > folks to correct the text.  (Or maybe on someone on linux-doc will
> > > feel inspired and get there ahead of me.  :-)
> > > 
> > 
> > Paul already started the work:
> > 
> > 	https://lore.kernel.org/lkml/19135936-06d7-4705-8bc8-bb31c2a478ca@paulmck-laptop/
> 
> Which reminds me, I need to forward-port that documentation to Mark's
> latest version.  ;-)

Except that it appears that Mark beat me to it.  ;-)

							Thanx, Paul



[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux