Re: [PATCH v3 19/19] fs: handle inode->i_version more efficiently

On Thu 21-12-17 06:25:55, Jeff Layton wrote: > Got it, I think. How about this (sorry for the unrelated deltas here): > > [PATCH] SQUASH: add memory barriers around i_version accesses Yep, this looks good to me. Honza > >

Re: [PATCH v3 19/19] fs: handle inode->i_version more efficiently

On Thu 21-12-17 06:25:55, Jeff Layton wrote: > Got it, I think. How about this (sorry for the unrelated deltas here): > > [PATCH] SQUASH: add memory barriers around i_version accesses Yep, this looks good to me. Honza > >

Re: [PATCH v3 19/19] fs: handle inode->i_version more efficiently

On Wed, 2017-12-20 at 17:41 +0100, Jan Kara wrote: > On Wed 20-12-17 09:03:06, Jeff Layton wrote: > > On Tue, 2017-12-19 at 09:07 +1100, Dave Chinner wrote: > > > On Mon, Dec 18, 2017 at 02:35:20PM -0500, Jeff Layton wrote: > > > > [PATCH] SQUASH: add memory barriers around i_version accesses > >

Re: [PATCH v3 19/19] fs: handle inode->i_version more efficiently

On Wed, 2017-12-20 at 17:41 +0100, Jan Kara wrote: > On Wed 20-12-17 09:03:06, Jeff Layton wrote: > > On Tue, 2017-12-19 at 09:07 +1100, Dave Chinner wrote: > > > On Mon, Dec 18, 2017 at 02:35:20PM -0500, Jeff Layton wrote: > > > > [PATCH] SQUASH: add memory barriers around i_version accesses > >

Re: [PATCH v3 19/19] fs: handle inode->i_version more efficiently

On Wed 20-12-17 09:03:06, Jeff Layton wrote: > On Tue, 2017-12-19 at 09:07 +1100, Dave Chinner wrote: > > On Mon, Dec 18, 2017 at 02:35:20PM -0500, Jeff Layton wrote: > > > [PATCH] SQUASH: add memory barriers around i_version accesses > > > > Why explicit memory barriers rather than annotating

Re: [PATCH v3 19/19] fs: handle inode->i_version more efficiently

On Wed 20-12-17 09:03:06, Jeff Layton wrote: > On Tue, 2017-12-19 at 09:07 +1100, Dave Chinner wrote: > > On Mon, Dec 18, 2017 at 02:35:20PM -0500, Jeff Layton wrote: > > > [PATCH] SQUASH: add memory barriers around i_version accesses > > > > Why explicit memory barriers rather than annotating

Re: [PATCH v3 19/19] fs: handle inode->i_version more efficiently

On Tue, 2017-12-19 at 09:07 +1100, Dave Chinner wrote: > On Mon, Dec 18, 2017 at 02:35:20PM -0500, Jeff Layton wrote: > > [PATCH] SQUASH: add memory barriers around i_version accesses > > Why explicit memory barriers rather than annotating the operations > with the required semantics and getting

Re: [PATCH v3 19/19] fs: handle inode->i_version more efficiently

On Tue, 2017-12-19 at 09:07 +1100, Dave Chinner wrote: > On Mon, Dec 18, 2017 at 02:35:20PM -0500, Jeff Layton wrote: > > [PATCH] SQUASH: add memory barriers around i_version accesses > > Why explicit memory barriers rather than annotating the operations > with the required semantics and getting

Re: [PATCH v3 19/19] fs: handle inode->i_version more efficiently

On Tue, 2017-12-19 at 10:29 +0100, Jan Kara wrote: > On Mon 18-12-17 12:22:20, Jeff Layton wrote: > > On Mon, 2017-12-18 at 17:34 +0100, Jan Kara wrote: > > > On Mon 18-12-17 10:11:56, Jeff Layton wrote: > > > > static inline bool > > > > inode_maybe_inc_iversion(struct inode *inode, bool force)

Re: [PATCH v3 19/19] fs: handle inode->i_version more efficiently

On Tue, 2017-12-19 at 10:29 +0100, Jan Kara wrote: > On Mon 18-12-17 12:22:20, Jeff Layton wrote: > > On Mon, 2017-12-18 at 17:34 +0100, Jan Kara wrote: > > > On Mon 18-12-17 10:11:56, Jeff Layton wrote: > > > > static inline bool > > > > inode_maybe_inc_iversion(struct inode *inode, bool force)

Re: [PATCH v3 19/19] fs: handle inode->i_version more efficiently

On Mon 18-12-17 12:22:20, Jeff Layton wrote: > On Mon, 2017-12-18 at 17:34 +0100, Jan Kara wrote: > > On Mon 18-12-17 10:11:56, Jeff Layton wrote: > > > static inline bool > > > inode_maybe_inc_iversion(struct inode *inode, bool force) > > > { > > > - atomic64_t *ivp = (atomic64_t *)>i_version;

Re: [PATCH v3 19/19] fs: handle inode->i_version more efficiently

On Mon 18-12-17 12:22:20, Jeff Layton wrote: > On Mon, 2017-12-18 at 17:34 +0100, Jan Kara wrote: > > On Mon 18-12-17 10:11:56, Jeff Layton wrote: > > > static inline bool > > > inode_maybe_inc_iversion(struct inode *inode, bool force) > > > { > > > - atomic64_t *ivp = (atomic64_t *)>i_version;

Re: [PATCH v3 19/19] fs: handle inode->i_version more efficiently

On Mon, Dec 18, 2017 at 02:35:20PM -0500, Jeff Layton wrote: > [PATCH] SQUASH: add memory barriers around i_version accesses Why explicit memory barriers rather than annotating the operations with the required semantics and getting the barriers the arch requires automatically? I suspect this

Re: [PATCH v3 19/19] fs: handle inode->i_version more efficiently

On Mon, Dec 18, 2017 at 02:35:20PM -0500, Jeff Layton wrote: > [PATCH] SQUASH: add memory barriers around i_version accesses Why explicit memory barriers rather than annotating the operations with the required semantics and getting the barriers the arch requires automatically? I suspect this

Re: [PATCH v3 19/19] fs: handle inode->i_version more efficiently

On Mon, 2017-12-18 at 12:36 -0500, J. Bruce Fields wrote: > On Mon, Dec 18, 2017 at 12:22:20PM -0500, Jeff Layton wrote: > > On Mon, 2017-12-18 at 17:34 +0100, Jan Kara wrote: > > > On Mon 18-12-17 10:11:56, Jeff Layton wrote: > > > > static inline bool > > > > inode_maybe_inc_iversion(struct

Re: [PATCH v3 19/19] fs: handle inode->i_version more efficiently

On Mon, 2017-12-18 at 12:36 -0500, J. Bruce Fields wrote: > On Mon, Dec 18, 2017 at 12:22:20PM -0500, Jeff Layton wrote: > > On Mon, 2017-12-18 at 17:34 +0100, Jan Kara wrote: > > > On Mon 18-12-17 10:11:56, Jeff Layton wrote: > > > > static inline bool > > > > inode_maybe_inc_iversion(struct

Re: [PATCH v3 19/19] fs: handle inode->i_version more efficiently

On Mon, Dec 18, 2017 at 12:22:20PM -0500, Jeff Layton wrote: > On Mon, 2017-12-18 at 17:34 +0100, Jan Kara wrote: > > On Mon 18-12-17 10:11:56, Jeff Layton wrote: > > > static inline bool > > > inode_maybe_inc_iversion(struct inode *inode, bool force) > > > { > > > - atomic64_t *ivp =

Re: [PATCH v3 19/19] fs: handle inode->i_version more efficiently

On Mon, Dec 18, 2017 at 12:22:20PM -0500, Jeff Layton wrote: > On Mon, 2017-12-18 at 17:34 +0100, Jan Kara wrote: > > On Mon 18-12-17 10:11:56, Jeff Layton wrote: > > > static inline bool > > > inode_maybe_inc_iversion(struct inode *inode, bool force) > > > { > > > - atomic64_t *ivp =

Re: [PATCH v3 19/19] fs: handle inode->i_version more efficiently

On Mon, 2017-12-18 at 17:34 +0100, Jan Kara wrote: > On Mon 18-12-17 10:11:56, Jeff Layton wrote: > > static inline bool > > inode_maybe_inc_iversion(struct inode *inode, bool force) > > { > > - atomic64_t *ivp = (atomic64_t *)>i_version; > > + u64 cur, old, new; > > > > -

Re: [PATCH v3 19/19] fs: handle inode->i_version more efficiently

On Mon, 2017-12-18 at 17:34 +0100, Jan Kara wrote: > On Mon 18-12-17 10:11:56, Jeff Layton wrote: > > static inline bool > > inode_maybe_inc_iversion(struct inode *inode, bool force) > > { > > - atomic64_t *ivp = (atomic64_t *)>i_version; > > + u64 cur, old, new; > > > > -

Re: [PATCH v3 19/19] fs: handle inode->i_version more efficiently

On Mon 18-12-17 10:11:56, Jeff Layton wrote: > static inline bool > inode_maybe_inc_iversion(struct inode *inode, bool force) > { > - atomic64_t *ivp = (atomic64_t *)>i_version; > + u64 cur, old, new; > > - atomic64_inc(ivp); > + cur = (u64)atomic64_read(>i_version); > +

Re: [PATCH v3 19/19] fs: handle inode->i_version more efficiently

On Mon 18-12-17 10:11:56, Jeff Layton wrote: > static inline bool > inode_maybe_inc_iversion(struct inode *inode, bool force) > { > - atomic64_t *ivp = (atomic64_t *)>i_version; > + u64 cur, old, new; > > - atomic64_inc(ivp); > + cur = (u64)atomic64_read(>i_version); > +

[PATCH v3 19/19] fs: handle inode->i_version more efficiently

From: Jeff Layton Since i_version is mostly treated as an opaque value, we can exploit that fact to avoid incrementing it when no one is watching. With that change, we can avoid incrementing the counter on writes, unless someone has queried for it since it was last

[PATCH v3 19/19] fs: handle inode->i_version more efficiently

From: Jeff Layton Since i_version is mostly treated as an opaque value, we can exploit that fact to avoid incrementing it when no one is watching. With that change, we can avoid incrementing the counter on writes, unless someone has queried for it since it was last incremented. If the a/c/mtime