2019-05-19 12:08:55 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
2005-04-16 22:20:36 +00:00
|
|
|
/*
|
|
|
|
* (C) 1997 Linus Torvalds
|
2011-05-27 13:28:01 +00:00
|
|
|
* (C) 1999 Andrea Arcangeli <andrea@suse.de> (dynamic inode allocation)
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
2011-12-07 18:17:19 +00:00
|
|
|
#include <linux/export.h>
|
2005-04-16 22:20:36 +00:00
|
|
|
#include <linux/fs.h>
|
2022-11-20 14:15:34 +00:00
|
|
|
#include <linux/filelock.h>
|
2005-04-16 22:20:36 +00:00
|
|
|
#include <linux/mm.h>
|
|
|
|
#include <linux/backing-dev.h>
|
|
|
|
#include <linux/hash.h>
|
|
|
|
#include <linux/swap.h>
|
|
|
|
#include <linux/security.h>
|
|
|
|
#include <linux/cdev.h>
|
2018-10-30 22:09:49 +00:00
|
|
|
#include <linux/memblock.h>
|
2009-05-21 21:01:26 +00:00
|
|
|
#include <linux/fsnotify.h>
|
2006-01-10 04:52:17 +00:00
|
|
|
#include <linux/mount.h>
|
2009-06-08 23:50:45 +00:00
|
|
|
#include <linux/posix_acl.h>
|
2011-05-27 13:28:01 +00:00
|
|
|
#include <linux/buffer_head.h> /* for inode_has_buffers */
|
2011-11-21 11:11:32 +00:00
|
|
|
#include <linux/ratelimit.h>
|
2013-08-28 00:17:58 +00:00
|
|
|
#include <linux/list_lru.h>
|
2018-01-29 11:41:30 +00:00
|
|
|
#include <linux/iversion.h>
|
2024-02-02 20:39:23 +00:00
|
|
|
#include <linux/rw_hint.h>
|
2024-10-02 21:27:22 +00:00
|
|
|
#include <linux/seq_file.h>
|
|
|
|
#include <linux/debugfs.h>
|
2015-02-02 05:37:00 +00:00
|
|
|
#include <trace/events/writeback.h>
|
2024-10-02 21:27:21 +00:00
|
|
|
#define CREATE_TRACE_POINTS
|
|
|
|
#include <trace/events/timestamp.h>
|
|
|
|
|
2011-03-22 11:23:41 +00:00
|
|
|
#include "internal.h"
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2011-03-22 11:23:36 +00:00
|
|
|
/*
|
2011-05-27 13:28:01 +00:00
|
|
|
* Inode locking rules:
|
2011-03-22 11:23:36 +00:00
|
|
|
*
|
|
|
|
* inode->i_lock protects:
|
2022-05-24 15:05:40 +00:00
|
|
|
* inode->i_state, inode->i_hash, __iget(), inode->i_io_list
|
2013-08-28 00:17:58 +00:00
|
|
|
* Inode LRU list locks protect:
|
2011-07-08 04:14:39 +00:00
|
|
|
* inode->i_sb->s_inode_lru, inode->i_lru
|
2015-03-04 17:37:22 +00:00
|
|
|
* inode->i_sb->s_inode_list_lock protects:
|
|
|
|
* inode->i_sb->s_inodes, inode->i_sb_list
|
2011-04-22 00:19:44 +00:00
|
|
|
* bdi->wb.list_lock protects:
|
2015-03-04 19:07:22 +00:00
|
|
|
* bdi->wb.b_{dirty,io,more_io,dirty_time}, inode->i_io_list
|
2011-03-22 11:23:42 +00:00
|
|
|
* inode_hash_lock protects:
|
|
|
|
* inode_hashtable, inode->i_hash
|
2011-03-22 11:23:36 +00:00
|
|
|
*
|
|
|
|
* Lock ordering:
|
2011-03-22 11:23:40 +00:00
|
|
|
*
|
2015-03-04 17:37:22 +00:00
|
|
|
* inode->i_sb->s_inode_list_lock
|
2011-03-22 11:23:40 +00:00
|
|
|
* inode->i_lock
|
2013-08-28 00:17:58 +00:00
|
|
|
* Inode LRU list locks
|
2011-03-22 11:23:41 +00:00
|
|
|
*
|
2011-04-22 00:19:44 +00:00
|
|
|
* bdi->wb.list_lock
|
2011-03-22 11:23:41 +00:00
|
|
|
* inode->i_lock
|
2011-03-22 11:23:42 +00:00
|
|
|
*
|
|
|
|
* inode_hash_lock
|
2015-03-04 17:37:22 +00:00
|
|
|
* inode->i_sb->s_inode_list_lock
|
2011-03-22 11:23:42 +00:00
|
|
|
* inode->i_lock
|
|
|
|
*
|
|
|
|
* iunique_lock
|
|
|
|
* inode_hash_lock
|
2011-03-22 11:23:36 +00:00
|
|
|
*/
|
|
|
|
|
2023-10-11 16:55:00 +00:00
|
|
|
static unsigned int i_hash_mask __ro_after_init;
|
|
|
|
static unsigned int i_hash_shift __ro_after_init;
|
|
|
|
static struct hlist_head *inode_hashtable __ro_after_init;
|
2011-03-22 11:23:42 +00:00
|
|
|
static __cacheline_aligned_in_smp DEFINE_SPINLOCK(inode_hash_lock);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2011-04-05 21:51:48 +00:00
|
|
|
/*
|
|
|
|
* Empty aops. Can be used for the cases where the user does not
|
|
|
|
* define any of the address_space operations.
|
|
|
|
*/
|
|
|
|
const struct address_space_operations empty_aops = {
|
|
|
|
};
|
|
|
|
EXPORT_SYMBOL(empty_aops);
|
|
|
|
|
fs: bump inode and dentry counters to long
This series reworks our current object cache shrinking infrastructure in
two main ways:
* Noticing that a lot of users copy and paste their own version of LRU
lists for objects, we put some effort in providing a generic version.
It is modeled after the filesystem users: dentries, inodes, and xfs
(for various tasks), but we expect that other users could benefit in
the near future with little or no modification. Let us know if you
have any issues.
* The underlying list_lru being proposed automatically and
transparently keeps the elements in per-node lists, and is able to
manipulate the node lists individually. Given this infrastructure, we
are able to modify the up-to-now hammer called shrink_slab to proceed
with node-reclaim instead of always searching memory from all over like
it has been doing.
Per-node lru lists are also expected to lead to less contention in the lru
locks on multi-node scans, since we are now no longer fighting for a
global lock. The locks usually disappear from the profilers with this
change.
Although we have no official benchmarks for this version - be our guest to
independently evaluate this - earlier versions of this series were
performance tested (details at
http://permalink.gmane.org/gmane.linux.kernel.mm/100537) yielding no
visible performance regressions while yielding a better qualitative
behavior in NUMA machines.
With this infrastructure in place, we can use the list_lru entry point to
provide memcg isolation and per-memcg targeted reclaim. Historically,
those two pieces of work have been posted together. This version presents
only the infrastructure work, deferring the memcg work for a later time,
so we can focus on getting this part tested. You can see more about the
history of such work at http://lwn.net/Articles/552769/
Dave Chinner (18):
dcache: convert dentry_stat.nr_unused to per-cpu counters
dentry: move to per-sb LRU locks
dcache: remove dentries from LRU before putting on dispose list
mm: new shrinker API
shrinker: convert superblock shrinkers to new API
list: add a new LRU list type
inode: convert inode lru list to generic lru list code.
dcache: convert to use new lru list infrastructure
list_lru: per-node list infrastructure
shrinker: add node awareness
fs: convert inode and dentry shrinking to be node aware
xfs: convert buftarg LRU to generic code
xfs: rework buffer dispose list tracking
xfs: convert dquot cache lru to list_lru
fs: convert fs shrinkers to new scan/count API
drivers: convert shrinkers to new count/scan API
shrinker: convert remaining shrinkers to count/scan API
shrinker: Kill old ->shrink API.
Glauber Costa (7):
fs: bump inode and dentry counters to long
super: fix calculation of shrinkable objects for small numbers
list_lru: per-node API
vmscan: per-node deferred work
i915: bail out earlier when shrinker cannot acquire mutex
hugepage: convert huge zero page shrinker to new shrinker API
list_lru: dynamically adjust node arrays
This patch:
There are situations in very large machines in which we can have a large
quantity of dirty inodes, unused dentries, etc. This is particularly true
when umounting a filesystem, where eventually since every live object will
eventually be discarded.
Dave Chinner reported a problem with this while experimenting with the
shrinker revamp patchset. So we believe it is time for a change. This
patch just moves int to longs. Machines where it matters should have a
big long anyway.
Signed-off-by: Glauber Costa <glommer@openvz.org>
Cc: Dave Chinner <dchinner@redhat.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Cc: Arve Hjønnevåg <arve@android.com>
Cc: Carlos Maiolino <cmaiolino@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Chuck Lever <chuck.lever@oracle.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Dave Chinner <dchinner@redhat.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Gleb Natapov <gleb@redhat.com>
Cc: Greg Thelen <gthelen@google.com>
Cc: J. Bruce Fields <bfields@redhat.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Jerome Glisse <jglisse@redhat.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Kent Overstreet <koverstreet@google.com>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Steven Whitehouse <swhiteho@redhat.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-08-28 00:17:53 +00:00
|
|
|
static DEFINE_PER_CPU(unsigned long, nr_inodes);
|
|
|
|
static DEFINE_PER_CPU(unsigned long, nr_unused);
|
2010-10-23 09:03:02 +00:00
|
|
|
|
2023-10-11 16:55:00 +00:00
|
|
|
static struct kmem_cache *inode_cachep __ro_after_init;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
fs: bump inode and dentry counters to long
This series reworks our current object cache shrinking infrastructure in
two main ways:
* Noticing that a lot of users copy and paste their own version of LRU
lists for objects, we put some effort in providing a generic version.
It is modeled after the filesystem users: dentries, inodes, and xfs
(for various tasks), but we expect that other users could benefit in
the near future with little or no modification. Let us know if you
have any issues.
* The underlying list_lru being proposed automatically and
transparently keeps the elements in per-node lists, and is able to
manipulate the node lists individually. Given this infrastructure, we
are able to modify the up-to-now hammer called shrink_slab to proceed
with node-reclaim instead of always searching memory from all over like
it has been doing.
Per-node lru lists are also expected to lead to less contention in the lru
locks on multi-node scans, since we are now no longer fighting for a
global lock. The locks usually disappear from the profilers with this
change.
Although we have no official benchmarks for this version - be our guest to
independently evaluate this - earlier versions of this series were
performance tested (details at
http://permalink.gmane.org/gmane.linux.kernel.mm/100537) yielding no
visible performance regressions while yielding a better qualitative
behavior in NUMA machines.
With this infrastructure in place, we can use the list_lru entry point to
provide memcg isolation and per-memcg targeted reclaim. Historically,
those two pieces of work have been posted together. This version presents
only the infrastructure work, deferring the memcg work for a later time,
so we can focus on getting this part tested. You can see more about the
history of such work at http://lwn.net/Articles/552769/
Dave Chinner (18):
dcache: convert dentry_stat.nr_unused to per-cpu counters
dentry: move to per-sb LRU locks
dcache: remove dentries from LRU before putting on dispose list
mm: new shrinker API
shrinker: convert superblock shrinkers to new API
list: add a new LRU list type
inode: convert inode lru list to generic lru list code.
dcache: convert to use new lru list infrastructure
list_lru: per-node list infrastructure
shrinker: add node awareness
fs: convert inode and dentry shrinking to be node aware
xfs: convert buftarg LRU to generic code
xfs: rework buffer dispose list tracking
xfs: convert dquot cache lru to list_lru
fs: convert fs shrinkers to new scan/count API
drivers: convert shrinkers to new count/scan API
shrinker: convert remaining shrinkers to count/scan API
shrinker: Kill old ->shrink API.
Glauber Costa (7):
fs: bump inode and dentry counters to long
super: fix calculation of shrinkable objects for small numbers
list_lru: per-node API
vmscan: per-node deferred work
i915: bail out earlier when shrinker cannot acquire mutex
hugepage: convert huge zero page shrinker to new shrinker API
list_lru: dynamically adjust node arrays
This patch:
There are situations in very large machines in which we can have a large
quantity of dirty inodes, unused dentries, etc. This is particularly true
when umounting a filesystem, where eventually since every live object will
eventually be discarded.
Dave Chinner reported a problem with this while experimenting with the
shrinker revamp patchset. So we believe it is time for a change. This
patch just moves int to longs. Machines where it matters should have a
big long anyway.
Signed-off-by: Glauber Costa <glommer@openvz.org>
Cc: Dave Chinner <dchinner@redhat.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Cc: Arve Hjønnevåg <arve@android.com>
Cc: Carlos Maiolino <cmaiolino@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Chuck Lever <chuck.lever@oracle.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Dave Chinner <dchinner@redhat.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Gleb Natapov <gleb@redhat.com>
Cc: Greg Thelen <gthelen@google.com>
Cc: J. Bruce Fields <bfields@redhat.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Jerome Glisse <jglisse@redhat.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Kent Overstreet <koverstreet@google.com>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Steven Whitehouse <swhiteho@redhat.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-08-28 00:17:53 +00:00
|
|
|
static long get_nr_inodes(void)
|
2010-10-23 09:03:02 +00:00
|
|
|
{
|
fs: use fast counters for vfs caches
percpu_counter library generates quite nasty code, so unless you need
to dynamically allocate counters or take fast approximate value, a
simple per cpu set of counters is much better.
The percpu_counter can never be made to work as well, because it has an
indirection from pointer to percpu memory, and it can't use direct
this_cpu_inc interfaces because it doesn't use static PER_CPU data, so
code will always be worse.
In the fastpath, it is the difference between this:
incl %gs:nr_dentry # nr_dentry
and this:
movl percpu_counter_batch(%rip), %edx # percpu_counter_batch,
movl $1, %esi #,
movq $nr_dentry, %rdi #,
call __percpu_counter_add # (plus I clobber registers)
__percpu_counter_add:
pushq %rbp #
movq %rsp, %rbp #,
subq $32, %rsp #,
movq %rbx, -24(%rbp) #,
movq %r12, -16(%rbp) #,
movq %r13, -8(%rbp) #,
movq %rdi, %rbx # fbc, fbc
#APP
# 216 "/home/npiggin/usr/src/linux-2.6/arch/x86/include/asm/thread_info.h" 1
movq %gs:kernel_stack,%rax #, pfo_ret__
# 0 "" 2
#NO_APP
incl -8124(%rax) # <variable>.preempt_count
movq 32(%rdi), %r12 # <variable>.counters, tcp_ptr__
#APP
# 78 "lib/percpu_counter.c" 1
add %gs:this_cpu_off, %r12 # this_cpu_off, tcp_ptr__
# 0 "" 2
#NO_APP
movslq (%r12),%r13 #* tcp_ptr__, tmp73
movslq %edx,%rax # batch, batch
addq %rsi, %r13 # amount, count
cmpq %rax, %r13 # batch, count
jge .L27 #,
negl %edx # tmp76
movslq %edx,%rdx # tmp76, tmp77
cmpq %rdx, %r13 # tmp77, count
jg .L28 #,
.L27:
movq %rbx, %rdi # fbc,
call _raw_spin_lock #
addq %r13, 8(%rbx) # count, <variable>.count
movq %rbx, %rdi # fbc,
movl $0, (%r12) #,* tcp_ptr__
call _raw_spin_unlock #
.L29:
#APP
# 216 "/home/npiggin/usr/src/linux-2.6/arch/x86/include/asm/thread_info.h" 1
movq %gs:kernel_stack,%rax #, pfo_ret__
# 0 "" 2
#NO_APP
decl -8124(%rax) # <variable>.preempt_count
movq -8136(%rax), %rax #, D.14625
testb $8, %al #, D.14625
jne .L32 #,
.L31:
movq -24(%rbp), %rbx #,
movq -16(%rbp), %r12 #,
movq -8(%rbp), %r13 #,
leave
ret
.p2align 4,,10
.p2align 3
.L28:
movl %r13d, (%r12) # count,*
jmp .L29 #
.L32:
call preempt_schedule #
.p2align 4,,6
jmp .L31 #
.size __percpu_counter_add, .-__percpu_counter_add
.p2align 4,,15
Signed-off-by: Nick Piggin <npiggin@kernel.dk>
2011-01-07 06:49:19 +00:00
|
|
|
int i;
|
fs: bump inode and dentry counters to long
This series reworks our current object cache shrinking infrastructure in
two main ways:
* Noticing that a lot of users copy and paste their own version of LRU
lists for objects, we put some effort in providing a generic version.
It is modeled after the filesystem users: dentries, inodes, and xfs
(for various tasks), but we expect that other users could benefit in
the near future with little or no modification. Let us know if you
have any issues.
* The underlying list_lru being proposed automatically and
transparently keeps the elements in per-node lists, and is able to
manipulate the node lists individually. Given this infrastructure, we
are able to modify the up-to-now hammer called shrink_slab to proceed
with node-reclaim instead of always searching memory from all over like
it has been doing.
Per-node lru lists are also expected to lead to less contention in the lru
locks on multi-node scans, since we are now no longer fighting for a
global lock. The locks usually disappear from the profilers with this
change.
Although we have no official benchmarks for this version - be our guest to
independently evaluate this - earlier versions of this series were
performance tested (details at
http://permalink.gmane.org/gmane.linux.kernel.mm/100537) yielding no
visible performance regressions while yielding a better qualitative
behavior in NUMA machines.
With this infrastructure in place, we can use the list_lru entry point to
provide memcg isolation and per-memcg targeted reclaim. Historically,
those two pieces of work have been posted together. This version presents
only the infrastructure work, deferring the memcg work for a later time,
so we can focus on getting this part tested. You can see more about the
history of such work at http://lwn.net/Articles/552769/
Dave Chinner (18):
dcache: convert dentry_stat.nr_unused to per-cpu counters
dentry: move to per-sb LRU locks
dcache: remove dentries from LRU before putting on dispose list
mm: new shrinker API
shrinker: convert superblock shrinkers to new API
list: add a new LRU list type
inode: convert inode lru list to generic lru list code.
dcache: convert to use new lru list infrastructure
list_lru: per-node list infrastructure
shrinker: add node awareness
fs: convert inode and dentry shrinking to be node aware
xfs: convert buftarg LRU to generic code
xfs: rework buffer dispose list tracking
xfs: convert dquot cache lru to list_lru
fs: convert fs shrinkers to new scan/count API
drivers: convert shrinkers to new count/scan API
shrinker: convert remaining shrinkers to count/scan API
shrinker: Kill old ->shrink API.
Glauber Costa (7):
fs: bump inode and dentry counters to long
super: fix calculation of shrinkable objects for small numbers
list_lru: per-node API
vmscan: per-node deferred work
i915: bail out earlier when shrinker cannot acquire mutex
hugepage: convert huge zero page shrinker to new shrinker API
list_lru: dynamically adjust node arrays
This patch:
There are situations in very large machines in which we can have a large
quantity of dirty inodes, unused dentries, etc. This is particularly true
when umounting a filesystem, where eventually since every live object will
eventually be discarded.
Dave Chinner reported a problem with this while experimenting with the
shrinker revamp patchset. So we believe it is time for a change. This
patch just moves int to longs. Machines where it matters should have a
big long anyway.
Signed-off-by: Glauber Costa <glommer@openvz.org>
Cc: Dave Chinner <dchinner@redhat.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Cc: Arve Hjønnevåg <arve@android.com>
Cc: Carlos Maiolino <cmaiolino@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Chuck Lever <chuck.lever@oracle.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Dave Chinner <dchinner@redhat.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Gleb Natapov <gleb@redhat.com>
Cc: Greg Thelen <gthelen@google.com>
Cc: J. Bruce Fields <bfields@redhat.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Jerome Glisse <jglisse@redhat.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Kent Overstreet <koverstreet@google.com>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Steven Whitehouse <swhiteho@redhat.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-08-28 00:17:53 +00:00
|
|
|
long sum = 0;
|
fs: use fast counters for vfs caches
percpu_counter library generates quite nasty code, so unless you need
to dynamically allocate counters or take fast approximate value, a
simple per cpu set of counters is much better.
The percpu_counter can never be made to work as well, because it has an
indirection from pointer to percpu memory, and it can't use direct
this_cpu_inc interfaces because it doesn't use static PER_CPU data, so
code will always be worse.
In the fastpath, it is the difference between this:
incl %gs:nr_dentry # nr_dentry
and this:
movl percpu_counter_batch(%rip), %edx # percpu_counter_batch,
movl $1, %esi #,
movq $nr_dentry, %rdi #,
call __percpu_counter_add # (plus I clobber registers)
__percpu_counter_add:
pushq %rbp #
movq %rsp, %rbp #,
subq $32, %rsp #,
movq %rbx, -24(%rbp) #,
movq %r12, -16(%rbp) #,
movq %r13, -8(%rbp) #,
movq %rdi, %rbx # fbc, fbc
#APP
# 216 "/home/npiggin/usr/src/linux-2.6/arch/x86/include/asm/thread_info.h" 1
movq %gs:kernel_stack,%rax #, pfo_ret__
# 0 "" 2
#NO_APP
incl -8124(%rax) # <variable>.preempt_count
movq 32(%rdi), %r12 # <variable>.counters, tcp_ptr__
#APP
# 78 "lib/percpu_counter.c" 1
add %gs:this_cpu_off, %r12 # this_cpu_off, tcp_ptr__
# 0 "" 2
#NO_APP
movslq (%r12),%r13 #* tcp_ptr__, tmp73
movslq %edx,%rax # batch, batch
addq %rsi, %r13 # amount, count
cmpq %rax, %r13 # batch, count
jge .L27 #,
negl %edx # tmp76
movslq %edx,%rdx # tmp76, tmp77
cmpq %rdx, %r13 # tmp77, count
jg .L28 #,
.L27:
movq %rbx, %rdi # fbc,
call _raw_spin_lock #
addq %r13, 8(%rbx) # count, <variable>.count
movq %rbx, %rdi # fbc,
movl $0, (%r12) #,* tcp_ptr__
call _raw_spin_unlock #
.L29:
#APP
# 216 "/home/npiggin/usr/src/linux-2.6/arch/x86/include/asm/thread_info.h" 1
movq %gs:kernel_stack,%rax #, pfo_ret__
# 0 "" 2
#NO_APP
decl -8124(%rax) # <variable>.preempt_count
movq -8136(%rax), %rax #, D.14625
testb $8, %al #, D.14625
jne .L32 #,
.L31:
movq -24(%rbp), %rbx #,
movq -16(%rbp), %r12 #,
movq -8(%rbp), %r13 #,
leave
ret
.p2align 4,,10
.p2align 3
.L28:
movl %r13d, (%r12) # count,*
jmp .L29 #
.L32:
call preempt_schedule #
.p2align 4,,6
jmp .L31 #
.size __percpu_counter_add, .-__percpu_counter_add
.p2align 4,,15
Signed-off-by: Nick Piggin <npiggin@kernel.dk>
2011-01-07 06:49:19 +00:00
|
|
|
for_each_possible_cpu(i)
|
|
|
|
sum += per_cpu(nr_inodes, i);
|
|
|
|
return sum < 0 ? 0 : sum;
|
2010-10-23 09:03:02 +00:00
|
|
|
}
|
|
|
|
|
fs: bump inode and dentry counters to long
This series reworks our current object cache shrinking infrastructure in
two main ways:
* Noticing that a lot of users copy and paste their own version of LRU
lists for objects, we put some effort in providing a generic version.
It is modeled after the filesystem users: dentries, inodes, and xfs
(for various tasks), but we expect that other users could benefit in
the near future with little or no modification. Let us know if you
have any issues.
* The underlying list_lru being proposed automatically and
transparently keeps the elements in per-node lists, and is able to
manipulate the node lists individually. Given this infrastructure, we
are able to modify the up-to-now hammer called shrink_slab to proceed
with node-reclaim instead of always searching memory from all over like
it has been doing.
Per-node lru lists are also expected to lead to less contention in the lru
locks on multi-node scans, since we are now no longer fighting for a
global lock. The locks usually disappear from the profilers with this
change.
Although we have no official benchmarks for this version - be our guest to
independently evaluate this - earlier versions of this series were
performance tested (details at
http://permalink.gmane.org/gmane.linux.kernel.mm/100537) yielding no
visible performance regressions while yielding a better qualitative
behavior in NUMA machines.
With this infrastructure in place, we can use the list_lru entry point to
provide memcg isolation and per-memcg targeted reclaim. Historically,
those two pieces of work have been posted together. This version presents
only the infrastructure work, deferring the memcg work for a later time,
so we can focus on getting this part tested. You can see more about the
history of such work at http://lwn.net/Articles/552769/
Dave Chinner (18):
dcache: convert dentry_stat.nr_unused to per-cpu counters
dentry: move to per-sb LRU locks
dcache: remove dentries from LRU before putting on dispose list
mm: new shrinker API
shrinker: convert superblock shrinkers to new API
list: add a new LRU list type
inode: convert inode lru list to generic lru list code.
dcache: convert to use new lru list infrastructure
list_lru: per-node list infrastructure
shrinker: add node awareness
fs: convert inode and dentry shrinking to be node aware
xfs: convert buftarg LRU to generic code
xfs: rework buffer dispose list tracking
xfs: convert dquot cache lru to list_lru
fs: convert fs shrinkers to new scan/count API
drivers: convert shrinkers to new count/scan API
shrinker: convert remaining shrinkers to count/scan API
shrinker: Kill old ->shrink API.
Glauber Costa (7):
fs: bump inode and dentry counters to long
super: fix calculation of shrinkable objects for small numbers
list_lru: per-node API
vmscan: per-node deferred work
i915: bail out earlier when shrinker cannot acquire mutex
hugepage: convert huge zero page shrinker to new shrinker API
list_lru: dynamically adjust node arrays
This patch:
There are situations in very large machines in which we can have a large
quantity of dirty inodes, unused dentries, etc. This is particularly true
when umounting a filesystem, where eventually since every live object will
eventually be discarded.
Dave Chinner reported a problem with this while experimenting with the
shrinker revamp patchset. So we believe it is time for a change. This
patch just moves int to longs. Machines where it matters should have a
big long anyway.
Signed-off-by: Glauber Costa <glommer@openvz.org>
Cc: Dave Chinner <dchinner@redhat.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Cc: Arve Hjønnevåg <arve@android.com>
Cc: Carlos Maiolino <cmaiolino@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Chuck Lever <chuck.lever@oracle.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Dave Chinner <dchinner@redhat.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Gleb Natapov <gleb@redhat.com>
Cc: Greg Thelen <gthelen@google.com>
Cc: J. Bruce Fields <bfields@redhat.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Jerome Glisse <jglisse@redhat.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Kent Overstreet <koverstreet@google.com>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Steven Whitehouse <swhiteho@redhat.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-08-28 00:17:53 +00:00
|
|
|
static inline long get_nr_inodes_unused(void)
|
2010-10-23 09:03:02 +00:00
|
|
|
{
|
2011-07-08 04:14:38 +00:00
|
|
|
int i;
|
fs: bump inode and dentry counters to long
This series reworks our current object cache shrinking infrastructure in
two main ways:
* Noticing that a lot of users copy and paste their own version of LRU
lists for objects, we put some effort in providing a generic version.
It is modeled after the filesystem users: dentries, inodes, and xfs
(for various tasks), but we expect that other users could benefit in
the near future with little or no modification. Let us know if you
have any issues.
* The underlying list_lru being proposed automatically and
transparently keeps the elements in per-node lists, and is able to
manipulate the node lists individually. Given this infrastructure, we
are able to modify the up-to-now hammer called shrink_slab to proceed
with node-reclaim instead of always searching memory from all over like
it has been doing.
Per-node lru lists are also expected to lead to less contention in the lru
locks on multi-node scans, since we are now no longer fighting for a
global lock. The locks usually disappear from the profilers with this
change.
Although we have no official benchmarks for this version - be our guest to
independently evaluate this - earlier versions of this series were
performance tested (details at
http://permalink.gmane.org/gmane.linux.kernel.mm/100537) yielding no
visible performance regressions while yielding a better qualitative
behavior in NUMA machines.
With this infrastructure in place, we can use the list_lru entry point to
provide memcg isolation and per-memcg targeted reclaim. Historically,
those two pieces of work have been posted together. This version presents
only the infrastructure work, deferring the memcg work for a later time,
so we can focus on getting this part tested. You can see more about the
history of such work at http://lwn.net/Articles/552769/
Dave Chinner (18):
dcache: convert dentry_stat.nr_unused to per-cpu counters
dentry: move to per-sb LRU locks
dcache: remove dentries from LRU before putting on dispose list
mm: new shrinker API
shrinker: convert superblock shrinkers to new API
list: add a new LRU list type
inode: convert inode lru list to generic lru list code.
dcache: convert to use new lru list infrastructure
list_lru: per-node list infrastructure
shrinker: add node awareness
fs: convert inode and dentry shrinking to be node aware
xfs: convert buftarg LRU to generic code
xfs: rework buffer dispose list tracking
xfs: convert dquot cache lru to list_lru
fs: convert fs shrinkers to new scan/count API
drivers: convert shrinkers to new count/scan API
shrinker: convert remaining shrinkers to count/scan API
shrinker: Kill old ->shrink API.
Glauber Costa (7):
fs: bump inode and dentry counters to long
super: fix calculation of shrinkable objects for small numbers
list_lru: per-node API
vmscan: per-node deferred work
i915: bail out earlier when shrinker cannot acquire mutex
hugepage: convert huge zero page shrinker to new shrinker API
list_lru: dynamically adjust node arrays
This patch:
There are situations in very large machines in which we can have a large
quantity of dirty inodes, unused dentries, etc. This is particularly true
when umounting a filesystem, where eventually since every live object will
eventually be discarded.
Dave Chinner reported a problem with this while experimenting with the
shrinker revamp patchset. So we believe it is time for a change. This
patch just moves int to longs. Machines where it matters should have a
big long anyway.
Signed-off-by: Glauber Costa <glommer@openvz.org>
Cc: Dave Chinner <dchinner@redhat.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Cc: Arve Hjønnevåg <arve@android.com>
Cc: Carlos Maiolino <cmaiolino@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Chuck Lever <chuck.lever@oracle.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Dave Chinner <dchinner@redhat.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Gleb Natapov <gleb@redhat.com>
Cc: Greg Thelen <gthelen@google.com>
Cc: J. Bruce Fields <bfields@redhat.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Jerome Glisse <jglisse@redhat.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Kent Overstreet <koverstreet@google.com>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Steven Whitehouse <swhiteho@redhat.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-08-28 00:17:53 +00:00
|
|
|
long sum = 0;
|
2011-07-08 04:14:38 +00:00
|
|
|
for_each_possible_cpu(i)
|
|
|
|
sum += per_cpu(nr_unused, i);
|
|
|
|
return sum < 0 ? 0 : sum;
|
2010-10-23 09:03:02 +00:00
|
|
|
}
|
|
|
|
|
fs: bump inode and dentry counters to long
This series reworks our current object cache shrinking infrastructure in
two main ways:
* Noticing that a lot of users copy and paste their own version of LRU
lists for objects, we put some effort in providing a generic version.
It is modeled after the filesystem users: dentries, inodes, and xfs
(for various tasks), but we expect that other users could benefit in
the near future with little or no modification. Let us know if you
have any issues.
* The underlying list_lru being proposed automatically and
transparently keeps the elements in per-node lists, and is able to
manipulate the node lists individually. Given this infrastructure, we
are able to modify the up-to-now hammer called shrink_slab to proceed
with node-reclaim instead of always searching memory from all over like
it has been doing.
Per-node lru lists are also expected to lead to less contention in the lru
locks on multi-node scans, since we are now no longer fighting for a
global lock. The locks usually disappear from the profilers with this
change.
Although we have no official benchmarks for this version - be our guest to
independently evaluate this - earlier versions of this series were
performance tested (details at
http://permalink.gmane.org/gmane.linux.kernel.mm/100537) yielding no
visible performance regressions while yielding a better qualitative
behavior in NUMA machines.
With this infrastructure in place, we can use the list_lru entry point to
provide memcg isolation and per-memcg targeted reclaim. Historically,
those two pieces of work have been posted together. This version presents
only the infrastructure work, deferring the memcg work for a later time,
so we can focus on getting this part tested. You can see more about the
history of such work at http://lwn.net/Articles/552769/
Dave Chinner (18):
dcache: convert dentry_stat.nr_unused to per-cpu counters
dentry: move to per-sb LRU locks
dcache: remove dentries from LRU before putting on dispose list
mm: new shrinker API
shrinker: convert superblock shrinkers to new API
list: add a new LRU list type
inode: convert inode lru list to generic lru list code.
dcache: convert to use new lru list infrastructure
list_lru: per-node list infrastructure
shrinker: add node awareness
fs: convert inode and dentry shrinking to be node aware
xfs: convert buftarg LRU to generic code
xfs: rework buffer dispose list tracking
xfs: convert dquot cache lru to list_lru
fs: convert fs shrinkers to new scan/count API
drivers: convert shrinkers to new count/scan API
shrinker: convert remaining shrinkers to count/scan API
shrinker: Kill old ->shrink API.
Glauber Costa (7):
fs: bump inode and dentry counters to long
super: fix calculation of shrinkable objects for small numbers
list_lru: per-node API
vmscan: per-node deferred work
i915: bail out earlier when shrinker cannot acquire mutex
hugepage: convert huge zero page shrinker to new shrinker API
list_lru: dynamically adjust node arrays
This patch:
There are situations in very large machines in which we can have a large
quantity of dirty inodes, unused dentries, etc. This is particularly true
when umounting a filesystem, where eventually since every live object will
eventually be discarded.
Dave Chinner reported a problem with this while experimenting with the
shrinker revamp patchset. So we believe it is time for a change. This
patch just moves int to longs. Machines where it matters should have a
big long anyway.
Signed-off-by: Glauber Costa <glommer@openvz.org>
Cc: Dave Chinner <dchinner@redhat.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Cc: Arve Hjønnevåg <arve@android.com>
Cc: Carlos Maiolino <cmaiolino@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Chuck Lever <chuck.lever@oracle.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Dave Chinner <dchinner@redhat.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Gleb Natapov <gleb@redhat.com>
Cc: Greg Thelen <gthelen@google.com>
Cc: J. Bruce Fields <bfields@redhat.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Jerome Glisse <jglisse@redhat.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Kent Overstreet <koverstreet@google.com>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Steven Whitehouse <swhiteho@redhat.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-08-28 00:17:53 +00:00
|
|
|
long get_nr_dirty_inodes(void)
|
2010-10-23 09:03:02 +00:00
|
|
|
{
|
fs: use fast counters for vfs caches
percpu_counter library generates quite nasty code, so unless you need
to dynamically allocate counters or take fast approximate value, a
simple per cpu set of counters is much better.
The percpu_counter can never be made to work as well, because it has an
indirection from pointer to percpu memory, and it can't use direct
this_cpu_inc interfaces because it doesn't use static PER_CPU data, so
code will always be worse.
In the fastpath, it is the difference between this:
incl %gs:nr_dentry # nr_dentry
and this:
movl percpu_counter_batch(%rip), %edx # percpu_counter_batch,
movl $1, %esi #,
movq $nr_dentry, %rdi #,
call __percpu_counter_add # (plus I clobber registers)
__percpu_counter_add:
pushq %rbp #
movq %rsp, %rbp #,
subq $32, %rsp #,
movq %rbx, -24(%rbp) #,
movq %r12, -16(%rbp) #,
movq %r13, -8(%rbp) #,
movq %rdi, %rbx # fbc, fbc
#APP
# 216 "/home/npiggin/usr/src/linux-2.6/arch/x86/include/asm/thread_info.h" 1
movq %gs:kernel_stack,%rax #, pfo_ret__
# 0 "" 2
#NO_APP
incl -8124(%rax) # <variable>.preempt_count
movq 32(%rdi), %r12 # <variable>.counters, tcp_ptr__
#APP
# 78 "lib/percpu_counter.c" 1
add %gs:this_cpu_off, %r12 # this_cpu_off, tcp_ptr__
# 0 "" 2
#NO_APP
movslq (%r12),%r13 #* tcp_ptr__, tmp73
movslq %edx,%rax # batch, batch
addq %rsi, %r13 # amount, count
cmpq %rax, %r13 # batch, count
jge .L27 #,
negl %edx # tmp76
movslq %edx,%rdx # tmp76, tmp77
cmpq %rdx, %r13 # tmp77, count
jg .L28 #,
.L27:
movq %rbx, %rdi # fbc,
call _raw_spin_lock #
addq %r13, 8(%rbx) # count, <variable>.count
movq %rbx, %rdi # fbc,
movl $0, (%r12) #,* tcp_ptr__
call _raw_spin_unlock #
.L29:
#APP
# 216 "/home/npiggin/usr/src/linux-2.6/arch/x86/include/asm/thread_info.h" 1
movq %gs:kernel_stack,%rax #, pfo_ret__
# 0 "" 2
#NO_APP
decl -8124(%rax) # <variable>.preempt_count
movq -8136(%rax), %rax #, D.14625
testb $8, %al #, D.14625
jne .L32 #,
.L31:
movq -24(%rbp), %rbx #,
movq -16(%rbp), %r12 #,
movq -8(%rbp), %r13 #,
leave
ret
.p2align 4,,10
.p2align 3
.L28:
movl %r13d, (%r12) # count,*
jmp .L29 #
.L32:
call preempt_schedule #
.p2align 4,,6
jmp .L31 #
.size __percpu_counter_add, .-__percpu_counter_add
.p2align 4,,15
Signed-off-by: Nick Piggin <npiggin@kernel.dk>
2011-01-07 06:49:19 +00:00
|
|
|
/* not actually dirty inodes, but a wild approximation */
|
fs: bump inode and dentry counters to long
This series reworks our current object cache shrinking infrastructure in
two main ways:
* Noticing that a lot of users copy and paste their own version of LRU
lists for objects, we put some effort in providing a generic version.
It is modeled after the filesystem users: dentries, inodes, and xfs
(for various tasks), but we expect that other users could benefit in
the near future with little or no modification. Let us know if you
have any issues.
* The underlying list_lru being proposed automatically and
transparently keeps the elements in per-node lists, and is able to
manipulate the node lists individually. Given this infrastructure, we
are able to modify the up-to-now hammer called shrink_slab to proceed
with node-reclaim instead of always searching memory from all over like
it has been doing.
Per-node lru lists are also expected to lead to less contention in the lru
locks on multi-node scans, since we are now no longer fighting for a
global lock. The locks usually disappear from the profilers with this
change.
Although we have no official benchmarks for this version - be our guest to
independently evaluate this - earlier versions of this series were
performance tested (details at
http://permalink.gmane.org/gmane.linux.kernel.mm/100537) yielding no
visible performance regressions while yielding a better qualitative
behavior in NUMA machines.
With this infrastructure in place, we can use the list_lru entry point to
provide memcg isolation and per-memcg targeted reclaim. Historically,
those two pieces of work have been posted together. This version presents
only the infrastructure work, deferring the memcg work for a later time,
so we can focus on getting this part tested. You can see more about the
history of such work at http://lwn.net/Articles/552769/
Dave Chinner (18):
dcache: convert dentry_stat.nr_unused to per-cpu counters
dentry: move to per-sb LRU locks
dcache: remove dentries from LRU before putting on dispose list
mm: new shrinker API
shrinker: convert superblock shrinkers to new API
list: add a new LRU list type
inode: convert inode lru list to generic lru list code.
dcache: convert to use new lru list infrastructure
list_lru: per-node list infrastructure
shrinker: add node awareness
fs: convert inode and dentry shrinking to be node aware
xfs: convert buftarg LRU to generic code
xfs: rework buffer dispose list tracking
xfs: convert dquot cache lru to list_lru
fs: convert fs shrinkers to new scan/count API
drivers: convert shrinkers to new count/scan API
shrinker: convert remaining shrinkers to count/scan API
shrinker: Kill old ->shrink API.
Glauber Costa (7):
fs: bump inode and dentry counters to long
super: fix calculation of shrinkable objects for small numbers
list_lru: per-node API
vmscan: per-node deferred work
i915: bail out earlier when shrinker cannot acquire mutex
hugepage: convert huge zero page shrinker to new shrinker API
list_lru: dynamically adjust node arrays
This patch:
There are situations in very large machines in which we can have a large
quantity of dirty inodes, unused dentries, etc. This is particularly true
when umounting a filesystem, where eventually since every live object will
eventually be discarded.
Dave Chinner reported a problem with this while experimenting with the
shrinker revamp patchset. So we believe it is time for a change. This
patch just moves int to longs. Machines where it matters should have a
big long anyway.
Signed-off-by: Glauber Costa <glommer@openvz.org>
Cc: Dave Chinner <dchinner@redhat.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Cc: Arve Hjønnevåg <arve@android.com>
Cc: Carlos Maiolino <cmaiolino@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Chuck Lever <chuck.lever@oracle.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Dave Chinner <dchinner@redhat.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Gleb Natapov <gleb@redhat.com>
Cc: Greg Thelen <gthelen@google.com>
Cc: J. Bruce Fields <bfields@redhat.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Jerome Glisse <jglisse@redhat.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Kent Overstreet <koverstreet@google.com>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Steven Whitehouse <swhiteho@redhat.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-08-28 00:17:53 +00:00
|
|
|
long nr_dirty = get_nr_inodes() - get_nr_inodes_unused();
|
2010-10-23 09:03:02 +00:00
|
|
|
return nr_dirty > 0 ? nr_dirty : 0;
|
|
|
|
}
|
|
|
|
|
2024-10-02 21:27:22 +00:00
|
|
|
#ifdef CONFIG_DEBUG_FS
|
|
|
|
static DEFINE_PER_CPU(long, mg_ctime_updates);
|
|
|
|
static DEFINE_PER_CPU(long, mg_fine_stamps);
|
|
|
|
static DEFINE_PER_CPU(long, mg_ctime_swaps);
|
|
|
|
|
|
|
|
static unsigned long get_mg_ctime_updates(void)
|
|
|
|
{
|
|
|
|
unsigned long sum = 0;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for_each_possible_cpu(i)
|
|
|
|
sum += data_race(per_cpu(mg_ctime_updates, i));
|
|
|
|
return sum;
|
|
|
|
}
|
|
|
|
|
|
|
|
static unsigned long get_mg_fine_stamps(void)
|
|
|
|
{
|
|
|
|
unsigned long sum = 0;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for_each_possible_cpu(i)
|
|
|
|
sum += data_race(per_cpu(mg_fine_stamps, i));
|
|
|
|
return sum;
|
|
|
|
}
|
|
|
|
|
|
|
|
static unsigned long get_mg_ctime_swaps(void)
|
|
|
|
{
|
|
|
|
unsigned long sum = 0;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for_each_possible_cpu(i)
|
|
|
|
sum += data_race(per_cpu(mg_ctime_swaps, i));
|
|
|
|
return sum;
|
|
|
|
}
|
|
|
|
|
|
|
|
#define mgtime_counter_inc(__var) this_cpu_inc(__var)
|
|
|
|
|
|
|
|
static int mgts_show(struct seq_file *s, void *p)
|
|
|
|
{
|
|
|
|
unsigned long ctime_updates = get_mg_ctime_updates();
|
|
|
|
unsigned long ctime_swaps = get_mg_ctime_swaps();
|
|
|
|
unsigned long fine_stamps = get_mg_fine_stamps();
|
|
|
|
unsigned long floor_swaps = timekeeping_get_mg_floor_swaps();
|
|
|
|
|
|
|
|
seq_printf(s, "%lu %lu %lu %lu\n",
|
|
|
|
ctime_updates, ctime_swaps, fine_stamps, floor_swaps);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
DEFINE_SHOW_ATTRIBUTE(mgts);
|
|
|
|
|
|
|
|
static int __init mg_debugfs_init(void)
|
|
|
|
{
|
|
|
|
debugfs_create_file("multigrain_timestamps", S_IFREG | S_IRUGO, NULL, NULL, &mgts_fops);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
late_initcall(mg_debugfs_init);
|
|
|
|
|
|
|
|
#else /* ! CONFIG_DEBUG_FS */
|
|
|
|
|
|
|
|
#define mgtime_counter_inc(__var) do { } while (0)
|
|
|
|
|
|
|
|
#endif /* CONFIG_DEBUG_FS */
|
|
|
|
|
2010-10-23 09:03:02 +00:00
|
|
|
/*
|
|
|
|
* Handle nr_inode sysctl
|
|
|
|
*/
|
|
|
|
#ifdef CONFIG_SYSCTL
|
2022-01-22 06:12:52 +00:00
|
|
|
/*
|
|
|
|
* Statistics gathering..
|
|
|
|
*/
|
|
|
|
static struct inodes_stat_t inodes_stat;
|
|
|
|
|
sysctl: treewide: constify the ctl_table argument of proc_handlers
const qualify the struct ctl_table argument in the proc_handler function
signatures. This is a prerequisite to moving the static ctl_table
structs into .rodata data which will ensure that proc_handler function
pointers cannot be modified.
This patch has been generated by the following coccinelle script:
```
virtual patch
@r1@
identifier ctl, write, buffer, lenp, ppos;
identifier func !~ "appldata_(timer|interval)_handler|sched_(rt|rr)_handler|rds_tcp_skbuf_handler|proc_sctp_do_(hmac_alg|rto_min|rto_max|udp_port|alpha_beta|auth|probe_interval)";
@@
int func(
- struct ctl_table *ctl
+ const struct ctl_table *ctl
,int write, void *buffer, size_t *lenp, loff_t *ppos);
@r2@
identifier func, ctl, write, buffer, lenp, ppos;
@@
int func(
- struct ctl_table *ctl
+ const struct ctl_table *ctl
,int write, void *buffer, size_t *lenp, loff_t *ppos)
{ ... }
@r3@
identifier func;
@@
int func(
- struct ctl_table *
+ const struct ctl_table *
,int , void *, size_t *, loff_t *);
@r4@
identifier func, ctl;
@@
int func(
- struct ctl_table *ctl
+ const struct ctl_table *ctl
,int , void *, size_t *, loff_t *);
@r5@
identifier func, write, buffer, lenp, ppos;
@@
int func(
- struct ctl_table *
+ const struct ctl_table *
,int write, void *buffer, size_t *lenp, loff_t *ppos);
```
* Code formatting was adjusted in xfs_sysctl.c to comply with code
conventions. The xfs_stats_clear_proc_handler,
xfs_panic_mask_proc_handler and xfs_deprecated_dointvec_minmax where
adjusted.
* The ctl_table argument in proc_watchdog_common was const qualified.
This is called from a proc_handler itself and is calling back into
another proc_handler, making it necessary to change it as part of the
proc_handler migration.
Co-developed-by: Thomas Weißschuh <linux@weissschuh.net>
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Co-developed-by: Joel Granados <j.granados@samsung.com>
Signed-off-by: Joel Granados <j.granados@samsung.com>
2024-07-24 18:59:29 +00:00
|
|
|
static int proc_nr_inodes(const struct ctl_table *table, int write, void *buffer,
|
2022-01-22 06:12:52 +00:00
|
|
|
size_t *lenp, loff_t *ppos)
|
2010-10-23 09:03:02 +00:00
|
|
|
{
|
|
|
|
inodes_stat.nr_inodes = get_nr_inodes();
|
2011-07-08 04:14:38 +00:00
|
|
|
inodes_stat.nr_unused = get_nr_inodes_unused();
|
fs: bump inode and dentry counters to long
This series reworks our current object cache shrinking infrastructure in
two main ways:
* Noticing that a lot of users copy and paste their own version of LRU
lists for objects, we put some effort in providing a generic version.
It is modeled after the filesystem users: dentries, inodes, and xfs
(for various tasks), but we expect that other users could benefit in
the near future with little or no modification. Let us know if you
have any issues.
* The underlying list_lru being proposed automatically and
transparently keeps the elements in per-node lists, and is able to
manipulate the node lists individually. Given this infrastructure, we
are able to modify the up-to-now hammer called shrink_slab to proceed
with node-reclaim instead of always searching memory from all over like
it has been doing.
Per-node lru lists are also expected to lead to less contention in the lru
locks on multi-node scans, since we are now no longer fighting for a
global lock. The locks usually disappear from the profilers with this
change.
Although we have no official benchmarks for this version - be our guest to
independently evaluate this - earlier versions of this series were
performance tested (details at
http://permalink.gmane.org/gmane.linux.kernel.mm/100537) yielding no
visible performance regressions while yielding a better qualitative
behavior in NUMA machines.
With this infrastructure in place, we can use the list_lru entry point to
provide memcg isolation and per-memcg targeted reclaim. Historically,
those two pieces of work have been posted together. This version presents
only the infrastructure work, deferring the memcg work for a later time,
so we can focus on getting this part tested. You can see more about the
history of such work at http://lwn.net/Articles/552769/
Dave Chinner (18):
dcache: convert dentry_stat.nr_unused to per-cpu counters
dentry: move to per-sb LRU locks
dcache: remove dentries from LRU before putting on dispose list
mm: new shrinker API
shrinker: convert superblock shrinkers to new API
list: add a new LRU list type
inode: convert inode lru list to generic lru list code.
dcache: convert to use new lru list infrastructure
list_lru: per-node list infrastructure
shrinker: add node awareness
fs: convert inode and dentry shrinking to be node aware
xfs: convert buftarg LRU to generic code
xfs: rework buffer dispose list tracking
xfs: convert dquot cache lru to list_lru
fs: convert fs shrinkers to new scan/count API
drivers: convert shrinkers to new count/scan API
shrinker: convert remaining shrinkers to count/scan API
shrinker: Kill old ->shrink API.
Glauber Costa (7):
fs: bump inode and dentry counters to long
super: fix calculation of shrinkable objects for small numbers
list_lru: per-node API
vmscan: per-node deferred work
i915: bail out earlier when shrinker cannot acquire mutex
hugepage: convert huge zero page shrinker to new shrinker API
list_lru: dynamically adjust node arrays
This patch:
There are situations in very large machines in which we can have a large
quantity of dirty inodes, unused dentries, etc. This is particularly true
when umounting a filesystem, where eventually since every live object will
eventually be discarded.
Dave Chinner reported a problem with this while experimenting with the
shrinker revamp patchset. So we believe it is time for a change. This
patch just moves int to longs. Machines where it matters should have a
big long anyway.
Signed-off-by: Glauber Costa <glommer@openvz.org>
Cc: Dave Chinner <dchinner@redhat.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Cc: Arve Hjønnevåg <arve@android.com>
Cc: Carlos Maiolino <cmaiolino@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Chuck Lever <chuck.lever@oracle.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Dave Chinner <dchinner@redhat.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Gleb Natapov <gleb@redhat.com>
Cc: Greg Thelen <gthelen@google.com>
Cc: J. Bruce Fields <bfields@redhat.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Jerome Glisse <jglisse@redhat.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Kent Overstreet <koverstreet@google.com>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Steven Whitehouse <swhiteho@redhat.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-08-28 00:17:53 +00:00
|
|
|
return proc_doulongvec_minmax(table, write, buffer, lenp, ppos);
|
2010-10-23 09:03:02 +00:00
|
|
|
}
|
2022-01-22 06:12:52 +00:00
|
|
|
|
|
|
|
static struct ctl_table inodes_sysctls[] = {
|
|
|
|
{
|
|
|
|
.procname = "inode-nr",
|
|
|
|
.data = &inodes_stat,
|
|
|
|
.maxlen = 2*sizeof(long),
|
|
|
|
.mode = 0444,
|
|
|
|
.proc_handler = proc_nr_inodes,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.procname = "inode-state",
|
|
|
|
.data = &inodes_stat,
|
|
|
|
.maxlen = 7*sizeof(long),
|
|
|
|
.mode = 0444,
|
|
|
|
.proc_handler = proc_nr_inodes,
|
|
|
|
},
|
|
|
|
};
|
|
|
|
|
|
|
|
static int __init init_fs_inode_sysctls(void)
|
|
|
|
{
|
|
|
|
register_sysctl_init("fs", inodes_sysctls);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
early_initcall(init_fs_inode_sysctls);
|
2010-10-23 09:03:02 +00:00
|
|
|
#endif
|
|
|
|
|
2014-11-19 04:38:21 +00:00
|
|
|
static int no_open(struct inode *inode, struct file *file)
|
|
|
|
{
|
|
|
|
return -ENXIO;
|
|
|
|
}
|
|
|
|
|
2008-10-30 06:32:23 +00:00
|
|
|
/**
|
2024-09-26 17:11:50 +00:00
|
|
|
* inode_init_always_gfp - perform inode structure initialisation
|
2009-01-06 22:41:13 +00:00
|
|
|
* @sb: superblock inode belongs to
|
|
|
|
* @inode: inode to initialise
|
2024-09-26 17:11:50 +00:00
|
|
|
* @gfp: allocation flags
|
2008-10-30 06:32:23 +00:00
|
|
|
*
|
|
|
|
* These are initializations that need to be done on every inode
|
|
|
|
* allocation as the fields are not initialised by slab allocation.
|
2024-09-26 17:11:50 +00:00
|
|
|
* If there are additional allocations required @gfp is used.
|
2008-10-30 06:32:23 +00:00
|
|
|
*/
|
2024-09-26 17:11:50 +00:00
|
|
|
int inode_init_always_gfp(struct super_block *sb, struct inode *inode, gfp_t gfp)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2009-09-22 00:01:11 +00:00
|
|
|
static const struct inode_operations empty_iops;
|
2014-11-19 04:38:21 +00:00
|
|
|
static const struct file_operations no_open_fops = {.open = no_open};
|
2009-03-31 14:05:54 +00:00
|
|
|
struct address_space *const mapping = &inode->i_data;
|
2008-10-30 06:32:23 +00:00
|
|
|
|
|
|
|
inode->i_sb = sb;
|
|
|
|
inode->i_blkbits = sb->s_blocksize_bits;
|
|
|
|
inode->i_flags = 0;
|
2024-06-11 12:06:24 +00:00
|
|
|
inode->i_state = 0;
|
2020-03-04 10:28:31 +00:00
|
|
|
atomic64_set(&inode->i_sequence, 0);
|
2008-10-30 06:32:23 +00:00
|
|
|
atomic_set(&inode->i_count, 1);
|
|
|
|
inode->i_op = &empty_iops;
|
2014-11-19 04:38:21 +00:00
|
|
|
inode->i_fop = &no_open_fops;
|
fs/inode.c: make inode_init_always() initialize i_ino to 0
Currently inode_init_always() doesn't initialize i_ino to 0. This is
unexpected because unlike the other inode fields that aren't initialized
by inode_init_always(), i_ino isn't guaranteed to end up back at its
initial value after the inode is freed. Only one filesystem (XFS)
actually sets set i_ino back to 0 when freeing its inodes.
So, callers of new_inode() see some random previous i_ino. Normally
that's fine, since normally i_ino isn't accessed before being set.
There can be edge cases where that isn't necessarily true, though.
The one I've run into is that on ext4, when creating an encrypted file,
the new file's encryption key has to be set up prior to the jbd2
transaction, and thus prior to i_ino being set. If something goes
wrong, fs/crypto/ may log warning or error messages, which normally
include i_ino. So it needs to know whether it is valid to include i_ino
yet or not. Also, on some files i_ino needs to be hashed for use in the
crypto, so fs/crypto/ needs to know whether that can be done yet or not.
There are ways this could be worked around, either in fs/crypto/ or in
fs/ext4/. But, it seems there's no reason not to just fix
inode_init_always() to do the expected thing and initialize i_ino to 0.
So, do that, and also remove the initialization in jfs_fill_super() that
becomes redundant.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2020-10-31 00:44:20 +00:00
|
|
|
inode->i_ino = 0;
|
2011-10-28 12:13:30 +00:00
|
|
|
inode->__i_nlink = 1;
|
2011-08-07 05:45:50 +00:00
|
|
|
inode->i_opflags = 0;
|
2016-09-29 15:48:39 +00:00
|
|
|
if (sb->s_xattr)
|
|
|
|
inode->i_opflags |= IOP_XATTR;
|
2024-11-13 14:17:51 +00:00
|
|
|
if (sb->s_type->fs_flags & FS_MGTIME)
|
|
|
|
inode->i_opflags |= IOP_MGTIME;
|
2012-02-08 15:07:50 +00:00
|
|
|
i_uid_write(inode, 0);
|
|
|
|
i_gid_write(inode, 0);
|
2008-10-30 06:32:23 +00:00
|
|
|
atomic_set(&inode->i_writecount, 0);
|
|
|
|
inode->i_size = 0;
|
fs: add fcntl() interface for setting/getting write life time hints
Define a set of write life time hints:
RWH_WRITE_LIFE_NOT_SET No hint information set
RWH_WRITE_LIFE_NONE No hints about write life time
RWH_WRITE_LIFE_SHORT Data written has a short life time
RWH_WRITE_LIFE_MEDIUM Data written has a medium life time
RWH_WRITE_LIFE_LONG Data written has a long life time
RWH_WRITE_LIFE_EXTREME Data written has an extremely long life time
The intent is for these values to be relative to each other, no
absolute meaning should be attached to these flag names.
Add an fcntl interface for querying these flags, and also for
setting them as well:
F_GET_RW_HINT Returns the read/write hint set on the
underlying inode.
F_SET_RW_HINT Set one of the above write hints on the
underlying inode.
F_GET_FILE_RW_HINT Returns the read/write hint set on the
file descriptor.
F_SET_FILE_RW_HINT Set one of the above write hints on the
file descriptor.
The user passes in a 64-bit pointer to get/set these values, and
the interface returns 0/-1 on success/error.
Sample program testing/implementing basic setting/getting of write
hints is below.
Add support for storing the write life time hint in the inode flags
and in struct file as well, and pass them to the kiocb flags. If
both a file and its corresponding inode has a write hint, then we
use the one in the file, if available. The file hint can be used
for sync/direct IO, for buffered writeback only the inode hint
is available.
This is in preparation for utilizing these hints in the block layer,
to guide on-media data placement.
/*
* writehint.c: get or set an inode write hint
*/
#include <stdio.h>
#include <fcntl.h>
#include <stdlib.h>
#include <unistd.h>
#include <stdbool.h>
#include <inttypes.h>
#ifndef F_GET_RW_HINT
#define F_LINUX_SPECIFIC_BASE 1024
#define F_GET_RW_HINT (F_LINUX_SPECIFIC_BASE + 11)
#define F_SET_RW_HINT (F_LINUX_SPECIFIC_BASE + 12)
#endif
static char *str[] = { "RWF_WRITE_LIFE_NOT_SET", "RWH_WRITE_LIFE_NONE",
"RWH_WRITE_LIFE_SHORT", "RWH_WRITE_LIFE_MEDIUM",
"RWH_WRITE_LIFE_LONG", "RWH_WRITE_LIFE_EXTREME" };
int main(int argc, char *argv[])
{
uint64_t hint;
int fd, ret;
if (argc < 2) {
fprintf(stderr, "%s: file <hint>\n", argv[0]);
return 1;
}
fd = open(argv[1], O_RDONLY);
if (fd < 0) {
perror("open");
return 2;
}
if (argc > 2) {
hint = atoi(argv[2]);
ret = fcntl(fd, F_SET_RW_HINT, &hint);
if (ret < 0) {
perror("fcntl: F_SET_RW_HINT");
return 4;
}
}
ret = fcntl(fd, F_GET_RW_HINT, &hint);
if (ret < 0) {
perror("fcntl: F_GET_RW_HINT");
return 3;
}
printf("%s: hint %s\n", argv[1], str[hint]);
close(fd);
return 0;
}
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2017-06-27 17:47:04 +00:00
|
|
|
inode->i_write_hint = WRITE_LIFE_NOT_SET;
|
2008-10-30 06:32:23 +00:00
|
|
|
inode->i_blocks = 0;
|
|
|
|
inode->i_bytes = 0;
|
|
|
|
inode->i_generation = 0;
|
|
|
|
inode->i_pipe = NULL;
|
|
|
|
inode->i_cdev = NULL;
|
2015-05-02 13:54:06 +00:00
|
|
|
inode->i_link = NULL;
|
parallel lookups machinery, part 2
We'll need to verify that there's neither a hashed nor in-lookup
dentry with desired parent/name before adding to in-lookup set.
One possible solution would be to hold the parent's ->d_lock through
both checks, but while the in-lookup set is relatively small at any
time, dcache is not. And holding the parent's ->d_lock through
something like __d_lookup_rcu() would suck too badly.
So we leave the parent's ->d_lock alone, which means that we watch
out for the following scenario:
* we verify that there's no hashed match
* existing in-lookup match gets hashed by another process
* we verify that there's no in-lookup matches and decide
that everything's fine.
Solution: per-directory kinda-sorta seqlock, bumped around the times
we hash something that used to be in-lookup or move (and hash)
something in place of in-lookup. Then the above would turn into
* read the counter
* do dcache lookup
* if no matches found, check for in-lookup matches
* if there had been none of those either, check if the
counter has changed; repeat if it has.
The "kinda-sorta" part is due to the fact that we don't have much spare
space in inode. There is a spare word (shared with i_bdev/i_cdev/i_pipe),
so the counter part is not a problem, but spinlock is a different story.
We could use the parent's ->d_lock, and it would be less painful in
terms of contention, for __d_add() it would be rather inconvenient to
grab; we could do that (using lock_parent()), but...
Fortunately, we can get serialization on the counter itself, and it
might be a good idea in general; we can use cmpxchg() in a loop to
get from even to odd and smp_store_release() from odd to even.
This commit adds the counter and updating logics; the readers will be
added in the next commit.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2016-04-15 04:58:55 +00:00
|
|
|
inode->i_dir_seq = 0;
|
2008-10-30 06:32:23 +00:00
|
|
|
inode->i_rdev = 0;
|
|
|
|
inode->dirtied_when = 0;
|
2009-02-04 14:06:57 +00:00
|
|
|
|
2016-02-16 21:34:39 +00:00
|
|
|
#ifdef CONFIG_CGROUP_WRITEBACK
|
|
|
|
inode->i_wb_frn_winner = 0;
|
|
|
|
inode->i_wb_frn_avg_time = 0;
|
|
|
|
inode->i_wb_frn_history = 0;
|
|
|
|
#endif
|
|
|
|
|
2008-10-30 06:32:23 +00:00
|
|
|
spin_lock_init(&inode->i_lock);
|
|
|
|
lockdep_set_class(&inode->i_lock, &sb->s_type->i_lock_key);
|
|
|
|
|
2016-04-15 19:08:36 +00:00
|
|
|
init_rwsem(&inode->i_rwsem);
|
|
|
|
lockdep_set_class(&inode->i_rwsem, &sb->s_type->i_mutex_key);
|
2008-10-30 06:32:23 +00:00
|
|
|
|
2011-06-24 18:29:43 +00:00
|
|
|
atomic_set(&inode->i_dio_count, 0);
|
2008-10-30 06:32:23 +00:00
|
|
|
|
|
|
|
mapping->a_ops = &empty_aops;
|
|
|
|
mapping->host = inode;
|
|
|
|
mapping->flags = 0;
|
2018-05-31 02:43:53 +00:00
|
|
|
mapping->wb_err = 0;
|
2014-08-08 21:25:25 +00:00
|
|
|
atomic_set(&mapping->i_mmap_writable, 0);
|
2019-09-23 22:38:03 +00:00
|
|
|
#ifdef CONFIG_READ_ONLY_THP_FOR_FS
|
|
|
|
atomic_set(&mapping->nr_thps, 0);
|
|
|
|
#endif
|
2009-01-06 22:39:23 +00:00
|
|
|
mapping_set_gfp_mask(mapping, GFP_HIGHUSER_MOVABLE);
|
2023-11-17 21:58:23 +00:00
|
|
|
mapping->i_private_data = NULL;
|
2008-10-30 06:32:23 +00:00
|
|
|
mapping->writeback_index = 0;
|
2021-09-01 08:44:03 +00:00
|
|
|
init_rwsem(&mapping->invalidate_lock);
|
|
|
|
lockdep_set_class_and_name(&mapping->invalidate_lock,
|
|
|
|
&sb->s_type->invalidate_lock_key,
|
|
|
|
"mapping.invalidate_lock");
|
2023-10-25 14:10:17 +00:00
|
|
|
if (sb->s_iflags & SB_I_STABLE_WRITES)
|
|
|
|
mapping_set_stable_writes(mapping);
|
2008-10-30 06:32:23 +00:00
|
|
|
inode->i_private = NULL;
|
|
|
|
inode->i_mapping = mapping;
|
2012-06-09 17:51:19 +00:00
|
|
|
INIT_HLIST_HEAD(&inode->i_dentry); /* buggered by rcu freeing */
|
2009-06-08 23:50:45 +00:00
|
|
|
#ifdef CONFIG_FS_POSIX_ACL
|
|
|
|
inode->i_acl = inode->i_default_acl = ACL_NOT_CACHED;
|
|
|
|
#endif
|
2008-10-30 06:32:23 +00:00
|
|
|
|
2009-05-21 21:01:26 +00:00
|
|
|
#ifdef CONFIG_FSNOTIFY
|
|
|
|
inode->i_fsnotify_mask = 0;
|
|
|
|
#endif
|
2015-01-16 20:05:54 +00:00
|
|
|
inode->i_flctx = NULL;
|
2022-08-16 04:08:58 +00:00
|
|
|
|
2024-09-26 17:11:50 +00:00
|
|
|
if (unlikely(security_inode_alloc(inode, gfp)))
|
2022-08-16 04:08:58 +00:00
|
|
|
return -ENOMEM;
|
2024-06-11 12:06:24 +00:00
|
|
|
|
fs: use fast counters for vfs caches
percpu_counter library generates quite nasty code, so unless you need
to dynamically allocate counters or take fast approximate value, a
simple per cpu set of counters is much better.
The percpu_counter can never be made to work as well, because it has an
indirection from pointer to percpu memory, and it can't use direct
this_cpu_inc interfaces because it doesn't use static PER_CPU data, so
code will always be worse.
In the fastpath, it is the difference between this:
incl %gs:nr_dentry # nr_dentry
and this:
movl percpu_counter_batch(%rip), %edx # percpu_counter_batch,
movl $1, %esi #,
movq $nr_dentry, %rdi #,
call __percpu_counter_add # (plus I clobber registers)
__percpu_counter_add:
pushq %rbp #
movq %rsp, %rbp #,
subq $32, %rsp #,
movq %rbx, -24(%rbp) #,
movq %r12, -16(%rbp) #,
movq %r13, -8(%rbp) #,
movq %rdi, %rbx # fbc, fbc
#APP
# 216 "/home/npiggin/usr/src/linux-2.6/arch/x86/include/asm/thread_info.h" 1
movq %gs:kernel_stack,%rax #, pfo_ret__
# 0 "" 2
#NO_APP
incl -8124(%rax) # <variable>.preempt_count
movq 32(%rdi), %r12 # <variable>.counters, tcp_ptr__
#APP
# 78 "lib/percpu_counter.c" 1
add %gs:this_cpu_off, %r12 # this_cpu_off, tcp_ptr__
# 0 "" 2
#NO_APP
movslq (%r12),%r13 #* tcp_ptr__, tmp73
movslq %edx,%rax # batch, batch
addq %rsi, %r13 # amount, count
cmpq %rax, %r13 # batch, count
jge .L27 #,
negl %edx # tmp76
movslq %edx,%rdx # tmp76, tmp77
cmpq %rdx, %r13 # tmp77, count
jg .L28 #,
.L27:
movq %rbx, %rdi # fbc,
call _raw_spin_lock #
addq %r13, 8(%rbx) # count, <variable>.count
movq %rbx, %rdi # fbc,
movl $0, (%r12) #,* tcp_ptr__
call _raw_spin_unlock #
.L29:
#APP
# 216 "/home/npiggin/usr/src/linux-2.6/arch/x86/include/asm/thread_info.h" 1
movq %gs:kernel_stack,%rax #, pfo_ret__
# 0 "" 2
#NO_APP
decl -8124(%rax) # <variable>.preempt_count
movq -8136(%rax), %rax #, D.14625
testb $8, %al #, D.14625
jne .L32 #,
.L31:
movq -24(%rbp), %rbx #,
movq -16(%rbp), %r12 #,
movq -8(%rbp), %r13 #,
leave
ret
.p2align 4,,10
.p2align 3
.L28:
movl %r13d, (%r12) # count,*
jmp .L29 #
.L32:
call preempt_schedule #
.p2align 4,,6
jmp .L31 #
.size __percpu_counter_add, .-__percpu_counter_add
.p2align 4,,15
Signed-off-by: Nick Piggin <npiggin@kernel.dk>
2011-01-07 06:49:19 +00:00
|
|
|
this_cpu_inc(nr_inodes);
|
2010-10-23 09:03:02 +00:00
|
|
|
|
2009-08-07 17:38:25 +00:00
|
|
|
return 0;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
2024-09-26 17:11:50 +00:00
|
|
|
EXPORT_SYMBOL(inode_init_always_gfp);
|
2008-10-30 06:32:23 +00:00
|
|
|
|
2019-04-10 18:43:44 +00:00
|
|
|
void free_inode_nonrcu(struct inode *inode)
|
|
|
|
{
|
|
|
|
kmem_cache_free(inode_cachep, inode);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(free_inode_nonrcu);
|
|
|
|
|
|
|
|
static void i_callback(struct rcu_head *head)
|
|
|
|
{
|
|
|
|
struct inode *inode = container_of(head, struct inode, i_rcu);
|
|
|
|
if (inode->free_inode)
|
|
|
|
inode->free_inode(inode);
|
|
|
|
else
|
|
|
|
free_inode_nonrcu(inode);
|
|
|
|
}
|
|
|
|
|
2008-10-30 06:32:23 +00:00
|
|
|
static struct inode *alloc_inode(struct super_block *sb)
|
|
|
|
{
|
2019-04-10 18:43:44 +00:00
|
|
|
const struct super_operations *ops = sb->s_op;
|
2008-10-30 06:32:23 +00:00
|
|
|
struct inode *inode;
|
|
|
|
|
2019-04-10 18:43:44 +00:00
|
|
|
if (ops->alloc_inode)
|
|
|
|
inode = ops->alloc_inode(sb);
|
2008-10-30 06:32:23 +00:00
|
|
|
else
|
2022-03-22 21:41:00 +00:00
|
|
|
inode = alloc_inode_sb(sb, inode_cachep, GFP_KERNEL);
|
2008-10-30 06:32:23 +00:00
|
|
|
|
2009-08-07 17:38:25 +00:00
|
|
|
if (!inode)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
if (unlikely(inode_init_always(sb, inode))) {
|
2019-04-10 18:43:44 +00:00
|
|
|
if (ops->destroy_inode) {
|
|
|
|
ops->destroy_inode(inode);
|
|
|
|
if (!ops->free_inode)
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
inode->free_inode = ops->free_inode;
|
|
|
|
i_callback(&inode->i_rcu);
|
2009-08-07 17:38:25 +00:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
return inode;
|
2008-10-30 06:32:23 +00:00
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2009-08-07 17:38:29 +00:00
|
|
|
void __destroy_inode(struct inode *inode)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2006-04-02 11:38:18 +00:00
|
|
|
BUG_ON(inode_has_buffers(inode));
|
2015-05-22 21:13:37 +00:00
|
|
|
inode_detach_wb(inode);
|
2005-04-16 22:20:36 +00:00
|
|
|
security_inode_free(inode);
|
2009-05-21 21:01:26 +00:00
|
|
|
fsnotify_inode_delete(inode);
|
2016-01-07 20:08:51 +00:00
|
|
|
locks_free_lock_context(inode);
|
2011-11-21 11:11:32 +00:00
|
|
|
if (!inode->i_nlink) {
|
|
|
|
WARN_ON(atomic_long_read(&inode->i_sb->s_remove_count) == 0);
|
|
|
|
atomic_long_dec(&inode->i_sb->s_remove_count);
|
|
|
|
}
|
|
|
|
|
2009-06-08 23:50:45 +00:00
|
|
|
#ifdef CONFIG_FS_POSIX_ACL
|
2016-03-24 13:38:37 +00:00
|
|
|
if (inode->i_acl && !is_uncached_acl(inode->i_acl))
|
2009-06-08 23:50:45 +00:00
|
|
|
posix_acl_release(inode->i_acl);
|
2016-03-24 13:38:37 +00:00
|
|
|
if (inode->i_default_acl && !is_uncached_acl(inode->i_default_acl))
|
2009-06-08 23:50:45 +00:00
|
|
|
posix_acl_release(inode->i_default_acl);
|
|
|
|
#endif
|
fs: use fast counters for vfs caches
percpu_counter library generates quite nasty code, so unless you need
to dynamically allocate counters or take fast approximate value, a
simple per cpu set of counters is much better.
The percpu_counter can never be made to work as well, because it has an
indirection from pointer to percpu memory, and it can't use direct
this_cpu_inc interfaces because it doesn't use static PER_CPU data, so
code will always be worse.
In the fastpath, it is the difference between this:
incl %gs:nr_dentry # nr_dentry
and this:
movl percpu_counter_batch(%rip), %edx # percpu_counter_batch,
movl $1, %esi #,
movq $nr_dentry, %rdi #,
call __percpu_counter_add # (plus I clobber registers)
__percpu_counter_add:
pushq %rbp #
movq %rsp, %rbp #,
subq $32, %rsp #,
movq %rbx, -24(%rbp) #,
movq %r12, -16(%rbp) #,
movq %r13, -8(%rbp) #,
movq %rdi, %rbx # fbc, fbc
#APP
# 216 "/home/npiggin/usr/src/linux-2.6/arch/x86/include/asm/thread_info.h" 1
movq %gs:kernel_stack,%rax #, pfo_ret__
# 0 "" 2
#NO_APP
incl -8124(%rax) # <variable>.preempt_count
movq 32(%rdi), %r12 # <variable>.counters, tcp_ptr__
#APP
# 78 "lib/percpu_counter.c" 1
add %gs:this_cpu_off, %r12 # this_cpu_off, tcp_ptr__
# 0 "" 2
#NO_APP
movslq (%r12),%r13 #* tcp_ptr__, tmp73
movslq %edx,%rax # batch, batch
addq %rsi, %r13 # amount, count
cmpq %rax, %r13 # batch, count
jge .L27 #,
negl %edx # tmp76
movslq %edx,%rdx # tmp76, tmp77
cmpq %rdx, %r13 # tmp77, count
jg .L28 #,
.L27:
movq %rbx, %rdi # fbc,
call _raw_spin_lock #
addq %r13, 8(%rbx) # count, <variable>.count
movq %rbx, %rdi # fbc,
movl $0, (%r12) #,* tcp_ptr__
call _raw_spin_unlock #
.L29:
#APP
# 216 "/home/npiggin/usr/src/linux-2.6/arch/x86/include/asm/thread_info.h" 1
movq %gs:kernel_stack,%rax #, pfo_ret__
# 0 "" 2
#NO_APP
decl -8124(%rax) # <variable>.preempt_count
movq -8136(%rax), %rax #, D.14625
testb $8, %al #, D.14625
jne .L32 #,
.L31:
movq -24(%rbp), %rbx #,
movq -16(%rbp), %r12 #,
movq -8(%rbp), %r13 #,
leave
ret
.p2align 4,,10
.p2align 3
.L28:
movl %r13d, (%r12) # count,*
jmp .L29 #
.L32:
call preempt_schedule #
.p2align 4,,6
jmp .L31 #
.size __percpu_counter_add, .-__percpu_counter_add
.p2align 4,,15
Signed-off-by: Nick Piggin <npiggin@kernel.dk>
2011-01-07 06:49:19 +00:00
|
|
|
this_cpu_dec(nr_inodes);
|
2009-08-07 17:38:29 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(__destroy_inode);
|
|
|
|
|
2010-10-06 08:48:55 +00:00
|
|
|
static void destroy_inode(struct inode *inode)
|
2009-08-07 17:38:29 +00:00
|
|
|
{
|
2019-04-10 18:43:44 +00:00
|
|
|
const struct super_operations *ops = inode->i_sb->s_op;
|
|
|
|
|
2010-10-21 00:49:30 +00:00
|
|
|
BUG_ON(!list_empty(&inode->i_lru));
|
2009-08-07 17:38:29 +00:00
|
|
|
__destroy_inode(inode);
|
2019-04-10 18:43:44 +00:00
|
|
|
if (ops->destroy_inode) {
|
|
|
|
ops->destroy_inode(inode);
|
|
|
|
if (!ops->free_inode)
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
inode->free_inode = ops->free_inode;
|
|
|
|
call_rcu(&inode->i_rcu, i_callback);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
2011-11-21 11:11:32 +00:00
|
|
|
/**
|
|
|
|
* drop_nlink - directly drop an inode's link count
|
|
|
|
* @inode: inode
|
|
|
|
*
|
|
|
|
* This is a low-level filesystem helper to replace any
|
|
|
|
* direct filesystem manipulation of i_nlink. In cases
|
|
|
|
* where we are attempting to track writes to the
|
|
|
|
* filesystem, a decrement to zero means an imminent
|
|
|
|
* write when the file is truncated and actually unlinked
|
|
|
|
* on the filesystem.
|
|
|
|
*/
|
|
|
|
void drop_nlink(struct inode *inode)
|
|
|
|
{
|
|
|
|
WARN_ON(inode->i_nlink == 0);
|
|
|
|
inode->__i_nlink--;
|
|
|
|
if (!inode->i_nlink)
|
|
|
|
atomic_long_inc(&inode->i_sb->s_remove_count);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(drop_nlink);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* clear_nlink - directly zero an inode's link count
|
|
|
|
* @inode: inode
|
|
|
|
*
|
|
|
|
* This is a low-level filesystem helper to replace any
|
|
|
|
* direct filesystem manipulation of i_nlink. See
|
|
|
|
* drop_nlink() for why we care about i_nlink hitting zero.
|
|
|
|
*/
|
|
|
|
void clear_nlink(struct inode *inode)
|
|
|
|
{
|
|
|
|
if (inode->i_nlink) {
|
|
|
|
inode->__i_nlink = 0;
|
|
|
|
atomic_long_inc(&inode->i_sb->s_remove_count);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(clear_nlink);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* set_nlink - directly set an inode's link count
|
|
|
|
* @inode: inode
|
|
|
|
* @nlink: new nlink (should be non-zero)
|
|
|
|
*
|
|
|
|
* This is a low-level filesystem helper to replace any
|
|
|
|
* direct filesystem manipulation of i_nlink.
|
|
|
|
*/
|
|
|
|
void set_nlink(struct inode *inode, unsigned int nlink)
|
|
|
|
{
|
|
|
|
if (!nlink) {
|
|
|
|
clear_nlink(inode);
|
|
|
|
} else {
|
|
|
|
/* Yes, some filesystems do change nlink from zero to one */
|
|
|
|
if (inode->i_nlink == 0)
|
|
|
|
atomic_long_dec(&inode->i_sb->s_remove_count);
|
|
|
|
|
|
|
|
inode->__i_nlink = nlink;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(set_nlink);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* inc_nlink - directly increment an inode's link count
|
|
|
|
* @inode: inode
|
|
|
|
*
|
|
|
|
* This is a low-level filesystem helper to replace any
|
|
|
|
* direct filesystem manipulation of i_nlink. Currently,
|
|
|
|
* it is only here for parity with dec_nlink().
|
|
|
|
*/
|
|
|
|
void inc_nlink(struct inode *inode)
|
|
|
|
{
|
2013-06-11 04:34:36 +00:00
|
|
|
if (unlikely(inode->i_nlink == 0)) {
|
|
|
|
WARN_ON(!(inode->i_state & I_LINKABLE));
|
2011-11-21 11:11:32 +00:00
|
|
|
atomic_long_dec(&inode->i_sb->s_remove_count);
|
2013-06-11 04:34:36 +00:00
|
|
|
}
|
2011-11-21 11:11:32 +00:00
|
|
|
|
|
|
|
inode->__i_nlink++;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(inc_nlink);
|
|
|
|
|
2018-03-07 01:30:34 +00:00
|
|
|
static void __address_space_init_once(struct address_space *mapping)
|
2011-02-23 12:49:47 +00:00
|
|
|
{
|
mm: fix page cache convergence regression
Since a28334862993 ("page cache: Finish XArray conversion"), on most
major Linux distributions, the page cache doesn't correctly transition
when the hot data set is changing, and leaves the new pages thrashing
indefinitely instead of kicking out the cold ones.
On a freshly booted, freshly ssh'd into virtual machine with 1G RAM
running stock Arch Linux:
[root@ham ~]# ./reclaimtest.sh
+ dd of=workingset-a bs=1M count=0 seek=600
+ cat workingset-a
+ cat workingset-a
+ cat workingset-a
+ cat workingset-a
+ cat workingset-a
+ cat workingset-a
+ cat workingset-a
+ cat workingset-a
+ ./mincore workingset-a
153600/153600 workingset-a
+ dd of=workingset-b bs=1M count=0 seek=600
+ cat workingset-b
+ cat workingset-b
+ cat workingset-b
+ cat workingset-b
+ ./mincore workingset-a workingset-b
104029/153600 workingset-a
120086/153600 workingset-b
+ cat workingset-b
+ cat workingset-b
+ cat workingset-b
+ cat workingset-b
+ ./mincore workingset-a workingset-b
104029/153600 workingset-a
120268/153600 workingset-b
workingset-b is a 600M file on a 1G host that is otherwise entirely
idle. No matter how often it's being accessed, it won't get cached.
While investigating, I noticed that the non-resident information gets
aggressively reclaimed - /proc/vmstat::workingset_nodereclaim. This is
a problem because a workingset transition like this relies on the
non-resident information tracked in the page cache tree of evicted
file ranges: when the cache faults are refaults of recently evicted
cache, we challenge the existing active set, and that allows a new
workingset to establish itself.
Tracing the shrinker that maintains this memory revealed that all page
cache tree nodes were allocated to the root cgroup. This is a problem,
because 1) the shrinker sizes the amount of non-resident information
it keeps to the size of the cgroup's other memory and 2) on most major
Linux distributions, only kernel threads live in the root cgroup and
everything else gets put into services or session groups:
[root@ham ~]# cat /proc/self/cgroup
0::/user.slice/user-0.slice/session-c1.scope
As a result, we basically maintain no non-resident information for the
workloads running on the system, thus breaking the caching algorithm.
Looking through the code, I found the culprit in the above-mentioned
patch: when switching from the radix tree to xarray, it dropped the
__GFP_ACCOUNT flag from the tree node allocations - the flag that
makes sure the allocated memory gets charged to and tracked by the
cgroup of the calling process - in this case, the one doing the fault.
To fix this, allow xarray users to specify per-tree flag that makes
xarray allocate nodes using __GFP_ACCOUNT. Then restore the page cache
tree annotation to request such cgroup tracking for the cache nodes.
With this patch applied, the page cache correctly converges on new
workingsets again after just a few iterations:
[root@ham ~]# ./reclaimtest.sh
+ dd of=workingset-a bs=1M count=0 seek=600
+ cat workingset-a
+ cat workingset-a
+ cat workingset-a
+ cat workingset-a
+ cat workingset-a
+ cat workingset-a
+ cat workingset-a
+ cat workingset-a
+ ./mincore workingset-a
153600/153600 workingset-a
+ dd of=workingset-b bs=1M count=0 seek=600
+ cat workingset-b
+ ./mincore workingset-a workingset-b
124607/153600 workingset-a
87876/153600 workingset-b
+ cat workingset-b
+ ./mincore workingset-a workingset-b
81313/153600 workingset-a
133321/153600 workingset-b
+ cat workingset-b
+ ./mincore workingset-a workingset-b
63036/153600 workingset-a
153600/153600 workingset-b
Cc: stable@vger.kernel.org # 4.20+
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Reviewed-by: Shakeel Butt <shakeelb@google.com>
Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
2019-05-24 14:12:46 +00:00
|
|
|
xa_init_flags(&mapping->i_pages, XA_FLAGS_LOCK_IRQ | XA_FLAGS_ACCOUNT);
|
2014-12-13 00:54:24 +00:00
|
|
|
init_rwsem(&mapping->i_mmap_rwsem);
|
2023-11-17 21:58:23 +00:00
|
|
|
INIT_LIST_HEAD(&mapping->i_private_list);
|
|
|
|
spin_lock_init(&mapping->i_private_lock);
|
2017-09-08 23:15:08 +00:00
|
|
|
mapping->i_mmap = RB_ROOT_CACHED;
|
2011-02-23 12:49:47 +00:00
|
|
|
}
|
2018-03-07 01:30:34 +00:00
|
|
|
|
|
|
|
void address_space_init_once(struct address_space *mapping)
|
|
|
|
{
|
|
|
|
memset(mapping, 0, sizeof(*mapping));
|
|
|
|
__address_space_init_once(mapping);
|
|
|
|
}
|
2011-02-23 12:49:47 +00:00
|
|
|
EXPORT_SYMBOL(address_space_init_once);
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/*
|
|
|
|
* These are initializations that only need to be done
|
|
|
|
* once, because the fields are idempotent across use
|
|
|
|
* of the inode, so let the slab aware of that.
|
|
|
|
*/
|
|
|
|
void inode_init_once(struct inode *inode)
|
|
|
|
{
|
|
|
|
memset(inode, 0, sizeof(*inode));
|
|
|
|
INIT_HLIST_NODE(&inode->i_hash);
|
|
|
|
INIT_LIST_HEAD(&inode->i_devices);
|
2015-03-04 19:07:22 +00:00
|
|
|
INIT_LIST_HEAD(&inode->i_io_list);
|
2016-07-26 22:21:50 +00:00
|
|
|
INIT_LIST_HEAD(&inode->i_wb_list);
|
2010-10-21 00:49:30 +00:00
|
|
|
INIT_LIST_HEAD(&inode->i_lru);
|
2022-03-31 20:29:00 +00:00
|
|
|
INIT_LIST_HEAD(&inode->i_sb_list);
|
2018-03-07 01:30:34 +00:00
|
|
|
__address_space_init_once(&inode->i_data);
|
2005-04-16 22:20:36 +00:00
|
|
|
i_size_ordered_init(inode);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(inode_init_once);
|
|
|
|
|
2008-07-26 02:45:34 +00:00
|
|
|
static void init_once(void *foo)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2009-03-31 14:05:54 +00:00
|
|
|
struct inode *inode = (struct inode *) foo;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2007-05-17 05:10:57 +00:00
|
|
|
inode_init_once(inode);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
2010-10-23 15:11:40 +00:00
|
|
|
/*
|
|
|
|
* get additional reference to inode; caller must already hold one.
|
|
|
|
*/
|
|
|
|
void ihold(struct inode *inode)
|
|
|
|
{
|
|
|
|
WARN_ON(atomic_inc_return(&inode->i_count) < 2);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(ihold);
|
|
|
|
|
vfs: keep inodes with page cache off the inode shrinker LRU
Historically (pre-2.5), the inode shrinker used to reclaim only empty
inodes and skip over those that still contained page cache. This caused
problems on highmem hosts: struct inode could put fill lowmem zones
before the cache was getting reclaimed in the highmem zones.
To address this, the inode shrinker started to strip page cache to
facilitate reclaiming lowmem. However, this comes with its own set of
problems: the shrinkers may drop actively used page cache just because
the inodes are not currently open or dirty - think working with a large
git tree. It further doesn't respect cgroup memory protection settings
and can cause priority inversions between containers.
Nowadays, the page cache also holds non-resident info for evicted cache
pages in order to detect refaults. We've come to rely heavily on this
data inside reclaim for protecting the cache workingset and driving swap
behavior. We also use it to quantify and report workload health through
psi. The latter in turn is used for fleet health monitoring, as well as
driving automated memory sizing of workloads and containers, proactive
reclaim and memory offloading schemes.
The consequences of dropping page cache prematurely is that we're seeing
subtle and not-so-subtle failures in all of the above-mentioned
scenarios, with the workload generally entering unexpected thrashing
states while losing the ability to reliably detect it.
To fix this on non-highmem systems at least, going back to rotating
inodes on the LRU isn't feasible. We've tried (commit a76cf1a474d7
("mm: don't reclaim inodes with many attached pages")) and failed
(commit 69056ee6a8a3 ("Revert "mm: don't reclaim inodes with many
attached pages"")).
The issue is mostly that shrinker pools attract pressure based on their
size, and when objects get skipped the shrinkers remember this as
deferred reclaim work. This accumulates excessive pressure on the
remaining inodes, and we can quickly eat into heavily used ones, or
dirty ones that require IO to reclaim, when there potentially is plenty
of cold, clean cache around still.
Instead, this patch keeps populated inodes off the inode LRU in the
first place - just like an open file or dirty state would. An otherwise
clean and unused inode then gets queued when the last cache entry
disappears. This solves the problem without reintroducing the reclaim
issues, and generally is a bit more scalable than having to wade through
potentially hundreds of thousands of busy inodes.
Locking is a bit tricky because the locks protecting the inode state
(i_lock) and the inode LRU (lru_list.lock) don't nest inside the
irq-safe page cache lock (i_pages.xa_lock). Page cache deletions are
serialized through i_lock, taken before the i_pages lock, to make sure
depopulated inodes are queued reliably. Additions may race with
deletions, but we'll check again in the shrinker. If additions race
with the shrinker itself, we're protected by the i_lock: if find_inode()
or iput() win, the shrinker will bail on the elevated i_count or
I_REFERENCED; if the shrinker wins and goes ahead with the inode, it
will set I_FREEING and inhibit further igets(), which will cause the
other side to create a new instance of the inode instead.
Link: https://lkml.kernel.org/r/20210614211904.14420-4-hannes@cmpxchg.org
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: Roman Gushchin <guro@fb.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: Dave Chinner <david@fromorbit.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-11-09 02:31:24 +00:00
|
|
|
static void __inode_add_lru(struct inode *inode, bool rotate)
|
2010-10-23 10:55:17 +00:00
|
|
|
{
|
vfs: keep inodes with page cache off the inode shrinker LRU
Historically (pre-2.5), the inode shrinker used to reclaim only empty
inodes and skip over those that still contained page cache. This caused
problems on highmem hosts: struct inode could put fill lowmem zones
before the cache was getting reclaimed in the highmem zones.
To address this, the inode shrinker started to strip page cache to
facilitate reclaiming lowmem. However, this comes with its own set of
problems: the shrinkers may drop actively used page cache just because
the inodes are not currently open or dirty - think working with a large
git tree. It further doesn't respect cgroup memory protection settings
and can cause priority inversions between containers.
Nowadays, the page cache also holds non-resident info for evicted cache
pages in order to detect refaults. We've come to rely heavily on this
data inside reclaim for protecting the cache workingset and driving swap
behavior. We also use it to quantify and report workload health through
psi. The latter in turn is used for fleet health monitoring, as well as
driving automated memory sizing of workloads and containers, proactive
reclaim and memory offloading schemes.
The consequences of dropping page cache prematurely is that we're seeing
subtle and not-so-subtle failures in all of the above-mentioned
scenarios, with the workload generally entering unexpected thrashing
states while losing the ability to reliably detect it.
To fix this on non-highmem systems at least, going back to rotating
inodes on the LRU isn't feasible. We've tried (commit a76cf1a474d7
("mm: don't reclaim inodes with many attached pages")) and failed
(commit 69056ee6a8a3 ("Revert "mm: don't reclaim inodes with many
attached pages"")).
The issue is mostly that shrinker pools attract pressure based on their
size, and when objects get skipped the shrinkers remember this as
deferred reclaim work. This accumulates excessive pressure on the
remaining inodes, and we can quickly eat into heavily used ones, or
dirty ones that require IO to reclaim, when there potentially is plenty
of cold, clean cache around still.
Instead, this patch keeps populated inodes off the inode LRU in the
first place - just like an open file or dirty state would. An otherwise
clean and unused inode then gets queued when the last cache entry
disappears. This solves the problem without reintroducing the reclaim
issues, and generally is a bit more scalable than having to wade through
potentially hundreds of thousands of busy inodes.
Locking is a bit tricky because the locks protecting the inode state
(i_lock) and the inode LRU (lru_list.lock) don't nest inside the
irq-safe page cache lock (i_pages.xa_lock). Page cache deletions are
serialized through i_lock, taken before the i_pages lock, to make sure
depopulated inodes are queued reliably. Additions may race with
deletions, but we'll check again in the shrinker. If additions race
with the shrinker itself, we're protected by the i_lock: if find_inode()
or iput() win, the shrinker will bail on the elevated i_count or
I_REFERENCED; if the shrinker wins and goes ahead with the inode, it
will set I_FREEING and inhibit further igets(), which will cause the
other side to create a new instance of the inode instead.
Link: https://lkml.kernel.org/r/20210614211904.14420-4-hannes@cmpxchg.org
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: Roman Gushchin <guro@fb.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: Dave Chinner <david@fromorbit.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-11-09 02:31:24 +00:00
|
|
|
if (inode->i_state & (I_DIRTY_ALL | I_SYNC | I_FREEING | I_WILL_FREE))
|
|
|
|
return;
|
|
|
|
if (atomic_read(&inode->i_count))
|
|
|
|
return;
|
|
|
|
if (!(inode->i_sb->s_flags & SB_ACTIVE))
|
|
|
|
return;
|
|
|
|
if (!mapping_shrinkable(&inode->i_data))
|
|
|
|
return;
|
|
|
|
|
list_lru: allow explicit memcg and NUMA node selection
Patch series "workload-specific and memory pressure-driven zswap
writeback", v8.
There are currently several issues with zswap writeback:
1. There is only a single global LRU for zswap, making it impossible to
perform worload-specific shrinking - an memcg under memory pressure
cannot determine which pages in the pool it owns, and often ends up
writing pages from other memcgs. This issue has been previously
observed in practice and mitigated by simply disabling
memcg-initiated shrinking:
https://lore.kernel.org/all/20230530232435.3097106-1-nphamcs@gmail.com/T/#u
But this solution leaves a lot to be desired, as we still do not
have an avenue for an memcg to free up its own memory locked up in
the zswap pool.
2. We only shrink the zswap pool when the user-defined limit is hit.
This means that if we set the limit too high, cold data that are
unlikely to be used again will reside in the pool, wasting precious
memory. It is hard to predict how much zswap space will be needed
ahead of time, as this depends on the workload (specifically, on
factors such as memory access patterns and compressibility of the
memory pages).
This patch series solves these issues by separating the global zswap LRU
into per-memcg and per-NUMA LRUs, and performs workload-specific (i.e
memcg- and NUMA-aware) zswap writeback under memory pressure. The new
shrinker does not have any parameter that must be tuned by the user, and
can be opted in or out on a per-memcg basis.
As a proof of concept, we ran the following synthetic benchmark: build the
linux kernel in a memory-limited cgroup, and allocate some cold data in
tmpfs to see if the shrinker could write them out and improved the overall
performance. Depending on the amount of cold data generated, we observe
from 14% to 35% reduction in kernel CPU time used in the kernel builds.
This patch (of 6):
The interface of list_lru is based on the assumption that the list node
and the data it represents belong to the same allocated on the correct
node/memcg. While this assumption is valid for existing slab objects LRU
such as dentries and inodes, it is undocumented, and rather inflexible for
certain potential list_lru users (such as the upcoming zswap shrinker and
the THP shrinker). It has caused us a lot of issues during our
development.
This patch changes list_lru interface so that the caller must explicitly
specify numa node and memcg when adding and removing objects. The old
list_lru_add() and list_lru_del() are renamed to list_lru_add_obj() and
list_lru_del_obj(), respectively.
It also extends the list_lru API with a new function, list_lru_putback,
which undoes a previous list_lru_isolate call. Unlike list_lru_add, it
does not increment the LRU node count (as list_lru_isolate does not
decrement the node count). list_lru_putback also allows for explicit
memcg and NUMA node selection.
Link: https://lkml.kernel.org/r/20231130194023.4102148-1-nphamcs@gmail.com
Link: https://lkml.kernel.org/r/20231130194023.4102148-2-nphamcs@gmail.com
Signed-off-by: Nhat Pham <nphamcs@gmail.com>
Suggested-by: Johannes Weiner <hannes@cmpxchg.org>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Tested-by: Bagas Sanjaya <bagasdotme@gmail.com>
Cc: Chris Li <chrisl@kernel.org>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Domenico Cerasuolo <cerasuolodomenico@gmail.com>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Muchun Song <muchun.song@linux.dev>
Cc: Roman Gushchin <roman.gushchin@linux.dev>
Cc: Seth Jennings <sjenning@redhat.com>
Cc: Shakeel Butt <shakeelb@google.com>
Cc: Shuah Khan <shuah@kernel.org>
Cc: Vitaly Wool <vitaly.wool@konsulko.com>
Cc: Yosry Ahmed <yosryahmed@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-11-30 19:40:18 +00:00
|
|
|
if (list_lru_add_obj(&inode->i_sb->s_inode_lru, &inode->i_lru))
|
2011-07-08 04:14:38 +00:00
|
|
|
this_cpu_inc(nr_unused);
|
vfs: keep inodes with page cache off the inode shrinker LRU
Historically (pre-2.5), the inode shrinker used to reclaim only empty
inodes and skip over those that still contained page cache. This caused
problems on highmem hosts: struct inode could put fill lowmem zones
before the cache was getting reclaimed in the highmem zones.
To address this, the inode shrinker started to strip page cache to
facilitate reclaiming lowmem. However, this comes with its own set of
problems: the shrinkers may drop actively used page cache just because
the inodes are not currently open or dirty - think working with a large
git tree. It further doesn't respect cgroup memory protection settings
and can cause priority inversions between containers.
Nowadays, the page cache also holds non-resident info for evicted cache
pages in order to detect refaults. We've come to rely heavily on this
data inside reclaim for protecting the cache workingset and driving swap
behavior. We also use it to quantify and report workload health through
psi. The latter in turn is used for fleet health monitoring, as well as
driving automated memory sizing of workloads and containers, proactive
reclaim and memory offloading schemes.
The consequences of dropping page cache prematurely is that we're seeing
subtle and not-so-subtle failures in all of the above-mentioned
scenarios, with the workload generally entering unexpected thrashing
states while losing the ability to reliably detect it.
To fix this on non-highmem systems at least, going back to rotating
inodes on the LRU isn't feasible. We've tried (commit a76cf1a474d7
("mm: don't reclaim inodes with many attached pages")) and failed
(commit 69056ee6a8a3 ("Revert "mm: don't reclaim inodes with many
attached pages"")).
The issue is mostly that shrinker pools attract pressure based on their
size, and when objects get skipped the shrinkers remember this as
deferred reclaim work. This accumulates excessive pressure on the
remaining inodes, and we can quickly eat into heavily used ones, or
dirty ones that require IO to reclaim, when there potentially is plenty
of cold, clean cache around still.
Instead, this patch keeps populated inodes off the inode LRU in the
first place - just like an open file or dirty state would. An otherwise
clean and unused inode then gets queued when the last cache entry
disappears. This solves the problem without reintroducing the reclaim
issues, and generally is a bit more scalable than having to wade through
potentially hundreds of thousands of busy inodes.
Locking is a bit tricky because the locks protecting the inode state
(i_lock) and the inode LRU (lru_list.lock) don't nest inside the
irq-safe page cache lock (i_pages.xa_lock). Page cache deletions are
serialized through i_lock, taken before the i_pages lock, to make sure
depopulated inodes are queued reliably. Additions may race with
deletions, but we'll check again in the shrinker. If additions race
with the shrinker itself, we're protected by the i_lock: if find_inode()
or iput() win, the shrinker will bail on the elevated i_count or
I_REFERENCED; if the shrinker wins and goes ahead with the inode, it
will set I_FREEING and inhibit further igets(), which will cause the
other side to create a new instance of the inode instead.
Link: https://lkml.kernel.org/r/20210614211904.14420-4-hannes@cmpxchg.org
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: Roman Gushchin <guro@fb.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: Dave Chinner <david@fromorbit.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-11-09 02:31:24 +00:00
|
|
|
else if (rotate)
|
2017-04-18 20:04:17 +00:00
|
|
|
inode->i_state |= I_REFERENCED;
|
2010-10-23 10:55:17 +00:00
|
|
|
}
|
2010-05-14 09:49:22 +00:00
|
|
|
|
2024-08-23 12:47:35 +00:00
|
|
|
struct wait_queue_head *inode_bit_waitqueue(struct wait_bit_queue_entry *wqe,
|
|
|
|
struct inode *inode, u32 bit)
|
|
|
|
{
|
|
|
|
void *bit_address;
|
|
|
|
|
|
|
|
bit_address = inode_state_wait_address(inode, bit);
|
|
|
|
init_wait_var_entry(wqe, bit_address, 0);
|
|
|
|
return __var_waitqueue(bit_address);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(inode_bit_waitqueue);
|
|
|
|
|
2012-11-27 00:29:51 +00:00
|
|
|
/*
|
|
|
|
* Add inode to LRU if needed (inode is unused and clean).
|
|
|
|
*
|
|
|
|
* Needs inode->i_lock held.
|
|
|
|
*/
|
|
|
|
void inode_add_lru(struct inode *inode)
|
|
|
|
{
|
vfs: keep inodes with page cache off the inode shrinker LRU
Historically (pre-2.5), the inode shrinker used to reclaim only empty
inodes and skip over those that still contained page cache. This caused
problems on highmem hosts: struct inode could put fill lowmem zones
before the cache was getting reclaimed in the highmem zones.
To address this, the inode shrinker started to strip page cache to
facilitate reclaiming lowmem. However, this comes with its own set of
problems: the shrinkers may drop actively used page cache just because
the inodes are not currently open or dirty - think working with a large
git tree. It further doesn't respect cgroup memory protection settings
and can cause priority inversions between containers.
Nowadays, the page cache also holds non-resident info for evicted cache
pages in order to detect refaults. We've come to rely heavily on this
data inside reclaim for protecting the cache workingset and driving swap
behavior. We also use it to quantify and report workload health through
psi. The latter in turn is used for fleet health monitoring, as well as
driving automated memory sizing of workloads and containers, proactive
reclaim and memory offloading schemes.
The consequences of dropping page cache prematurely is that we're seeing
subtle and not-so-subtle failures in all of the above-mentioned
scenarios, with the workload generally entering unexpected thrashing
states while losing the ability to reliably detect it.
To fix this on non-highmem systems at least, going back to rotating
inodes on the LRU isn't feasible. We've tried (commit a76cf1a474d7
("mm: don't reclaim inodes with many attached pages")) and failed
(commit 69056ee6a8a3 ("Revert "mm: don't reclaim inodes with many
attached pages"")).
The issue is mostly that shrinker pools attract pressure based on their
size, and when objects get skipped the shrinkers remember this as
deferred reclaim work. This accumulates excessive pressure on the
remaining inodes, and we can quickly eat into heavily used ones, or
dirty ones that require IO to reclaim, when there potentially is plenty
of cold, clean cache around still.
Instead, this patch keeps populated inodes off the inode LRU in the
first place - just like an open file or dirty state would. An otherwise
clean and unused inode then gets queued when the last cache entry
disappears. This solves the problem without reintroducing the reclaim
issues, and generally is a bit more scalable than having to wade through
potentially hundreds of thousands of busy inodes.
Locking is a bit tricky because the locks protecting the inode state
(i_lock) and the inode LRU (lru_list.lock) don't nest inside the
irq-safe page cache lock (i_pages.xa_lock). Page cache deletions are
serialized through i_lock, taken before the i_pages lock, to make sure
depopulated inodes are queued reliably. Additions may race with
deletions, but we'll check again in the shrinker. If additions race
with the shrinker itself, we're protected by the i_lock: if find_inode()
or iput() win, the shrinker will bail on the elevated i_count or
I_REFERENCED; if the shrinker wins and goes ahead with the inode, it
will set I_FREEING and inhibit further igets(), which will cause the
other side to create a new instance of the inode instead.
Link: https://lkml.kernel.org/r/20210614211904.14420-4-hannes@cmpxchg.org
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: Roman Gushchin <guro@fb.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: Dave Chinner <david@fromorbit.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-11-09 02:31:24 +00:00
|
|
|
__inode_add_lru(inode, false);
|
2012-11-27 00:29:51 +00:00
|
|
|
}
|
|
|
|
|
2010-10-23 10:55:17 +00:00
|
|
|
static void inode_lru_list_del(struct inode *inode)
|
|
|
|
{
|
list_lru: allow explicit memcg and NUMA node selection
Patch series "workload-specific and memory pressure-driven zswap
writeback", v8.
There are currently several issues with zswap writeback:
1. There is only a single global LRU for zswap, making it impossible to
perform worload-specific shrinking - an memcg under memory pressure
cannot determine which pages in the pool it owns, and often ends up
writing pages from other memcgs. This issue has been previously
observed in practice and mitigated by simply disabling
memcg-initiated shrinking:
https://lore.kernel.org/all/20230530232435.3097106-1-nphamcs@gmail.com/T/#u
But this solution leaves a lot to be desired, as we still do not
have an avenue for an memcg to free up its own memory locked up in
the zswap pool.
2. We only shrink the zswap pool when the user-defined limit is hit.
This means that if we set the limit too high, cold data that are
unlikely to be used again will reside in the pool, wasting precious
memory. It is hard to predict how much zswap space will be needed
ahead of time, as this depends on the workload (specifically, on
factors such as memory access patterns and compressibility of the
memory pages).
This patch series solves these issues by separating the global zswap LRU
into per-memcg and per-NUMA LRUs, and performs workload-specific (i.e
memcg- and NUMA-aware) zswap writeback under memory pressure. The new
shrinker does not have any parameter that must be tuned by the user, and
can be opted in or out on a per-memcg basis.
As a proof of concept, we ran the following synthetic benchmark: build the
linux kernel in a memory-limited cgroup, and allocate some cold data in
tmpfs to see if the shrinker could write them out and improved the overall
performance. Depending on the amount of cold data generated, we observe
from 14% to 35% reduction in kernel CPU time used in the kernel builds.
This patch (of 6):
The interface of list_lru is based on the assumption that the list node
and the data it represents belong to the same allocated on the correct
node/memcg. While this assumption is valid for existing slab objects LRU
such as dentries and inodes, it is undocumented, and rather inflexible for
certain potential list_lru users (such as the upcoming zswap shrinker and
the THP shrinker). It has caused us a lot of issues during our
development.
This patch changes list_lru interface so that the caller must explicitly
specify numa node and memcg when adding and removing objects. The old
list_lru_add() and list_lru_del() are renamed to list_lru_add_obj() and
list_lru_del_obj(), respectively.
It also extends the list_lru API with a new function, list_lru_putback,
which undoes a previous list_lru_isolate call. Unlike list_lru_add, it
does not increment the LRU node count (as list_lru_isolate does not
decrement the node count). list_lru_putback also allows for explicit
memcg and NUMA node selection.
Link: https://lkml.kernel.org/r/20231130194023.4102148-1-nphamcs@gmail.com
Link: https://lkml.kernel.org/r/20231130194023.4102148-2-nphamcs@gmail.com
Signed-off-by: Nhat Pham <nphamcs@gmail.com>
Suggested-by: Johannes Weiner <hannes@cmpxchg.org>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Tested-by: Bagas Sanjaya <bagasdotme@gmail.com>
Cc: Chris Li <chrisl@kernel.org>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Domenico Cerasuolo <cerasuolodomenico@gmail.com>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Muchun Song <muchun.song@linux.dev>
Cc: Roman Gushchin <roman.gushchin@linux.dev>
Cc: Seth Jennings <sjenning@redhat.com>
Cc: Shakeel Butt <shakeelb@google.com>
Cc: Shuah Khan <shuah@kernel.org>
Cc: Vitaly Wool <vitaly.wool@konsulko.com>
Cc: Yosry Ahmed <yosryahmed@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-11-30 19:40:18 +00:00
|
|
|
if (list_lru_del_obj(&inode->i_sb->s_inode_lru, &inode->i_lru))
|
2011-07-08 04:14:38 +00:00
|
|
|
this_cpu_dec(nr_unused);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
vfs: Don't evict inode under the inode lru traversing context
The inode reclaiming process(See function prune_icache_sb) collects all
reclaimable inodes and mark them with I_FREEING flag at first, at that
time, other processes will be stuck if they try getting these inodes
(See function find_inode_fast), then the reclaiming process destroy the
inodes by function dispose_list(). Some filesystems(eg. ext4 with
ea_inode feature, ubifs with xattr) may do inode lookup in the inode
evicting callback function, if the inode lookup is operated under the
inode lru traversing context, deadlock problems may happen.
Case 1: In function ext4_evict_inode(), the ea inode lookup could happen
if ea_inode feature is enabled, the lookup process will be stuck
under the evicting context like this:
1. File A has inode i_reg and an ea inode i_ea
2. getfattr(A, xattr_buf) // i_ea is added into lru // lru->i_ea
3. Then, following three processes running like this:
PA PB
echo 2 > /proc/sys/vm/drop_caches
shrink_slab
prune_dcache_sb
// i_reg is added into lru, lru->i_ea->i_reg
prune_icache_sb
list_lru_walk_one
inode_lru_isolate
i_ea->i_state |= I_FREEING // set inode state
inode_lru_isolate
__iget(i_reg)
spin_unlock(&i_reg->i_lock)
spin_unlock(lru_lock)
rm file A
i_reg->nlink = 0
iput(i_reg) // i_reg->nlink is 0, do evict
ext4_evict_inode
ext4_xattr_delete_inode
ext4_xattr_inode_dec_ref_all
ext4_xattr_inode_iget
ext4_iget(i_ea->i_ino)
iget_locked
find_inode_fast
__wait_on_freeing_inode(i_ea) ----→ AA deadlock
dispose_list // cannot be executed by prune_icache_sb
wake_up_bit(&i_ea->i_state)
Case 2: In deleted inode writing function ubifs_jnl_write_inode(), file
deleting process holds BASEHD's wbuf->io_mutex while getting the
xattr inode, which could race with inode reclaiming process(The
reclaiming process could try locking BASEHD's wbuf->io_mutex in
inode evicting function), then an ABBA deadlock problem would
happen as following:
1. File A has inode ia and a xattr(with inode ixa), regular file B has
inode ib and a xattr.
2. getfattr(A, xattr_buf) // ixa is added into lru // lru->ixa
3. Then, following three processes running like this:
PA PB PC
echo 2 > /proc/sys/vm/drop_caches
shrink_slab
prune_dcache_sb
// ib and ia are added into lru, lru->ixa->ib->ia
prune_icache_sb
list_lru_walk_one
inode_lru_isolate
ixa->i_state |= I_FREEING // set inode state
inode_lru_isolate
__iget(ib)
spin_unlock(&ib->i_lock)
spin_unlock(lru_lock)
rm file B
ib->nlink = 0
rm file A
iput(ia)
ubifs_evict_inode(ia)
ubifs_jnl_delete_inode(ia)
ubifs_jnl_write_inode(ia)
make_reservation(BASEHD) // Lock wbuf->io_mutex
ubifs_iget(ixa->i_ino)
iget_locked
find_inode_fast
__wait_on_freeing_inode(ixa)
| iput(ib) // ib->nlink is 0, do evict
| ubifs_evict_inode
| ubifs_jnl_delete_inode(ib)
↓ ubifs_jnl_write_inode
ABBA deadlock ←-----make_reservation(BASEHD)
dispose_list // cannot be executed by prune_icache_sb
wake_up_bit(&ixa->i_state)
Fix the possible deadlock by using new inode state flag I_LRU_ISOLATING
to pin the inode in memory while inode_lru_isolate() reclaims its pages
instead of using ordinary inode reference. This way inode deletion
cannot be triggered from inode_lru_isolate() thus avoiding the deadlock.
evict() is made to wait for I_LRU_ISOLATING to be cleared before
proceeding with inode cleanup.
Link: https://lore.kernel.org/all/37c29c42-7685-d1f0-067d-63582ffac405@huaweicloud.com/
Link: https://bugzilla.kernel.org/show_bug.cgi?id=219022
Fixes: e50e5129f384 ("ext4: xattr-in-inode support")
Fixes: 7959cf3a7506 ("ubifs: journal: Handle xattrs like files")
Cc: stable@vger.kernel.org
Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
Link: https://lore.kernel.org/r/20240809031628.1069873-1-chengzhihao@huaweicloud.com
Reviewed-by: Jan Kara <jack@suse.cz>
Suggested-by: Jan Kara <jack@suse.cz>
Suggested-by: Mateusz Guzik <mjguzik@gmail.com>
Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-08-09 03:16:28 +00:00
|
|
|
static void inode_pin_lru_isolating(struct inode *inode)
|
|
|
|
{
|
|
|
|
lockdep_assert_held(&inode->i_lock);
|
|
|
|
WARN_ON(inode->i_state & (I_LRU_ISOLATING | I_FREEING | I_WILL_FREE));
|
|
|
|
inode->i_state |= I_LRU_ISOLATING;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void inode_unpin_lru_isolating(struct inode *inode)
|
|
|
|
{
|
|
|
|
spin_lock(&inode->i_lock);
|
|
|
|
WARN_ON(!(inode->i_state & I_LRU_ISOLATING));
|
|
|
|
inode->i_state &= ~I_LRU_ISOLATING;
|
2024-08-23 12:47:39 +00:00
|
|
|
/* Called with inode->i_lock which ensures memory ordering. */
|
|
|
|
inode_wake_up_bit(inode, __I_LRU_ISOLATING);
|
vfs: Don't evict inode under the inode lru traversing context
The inode reclaiming process(See function prune_icache_sb) collects all
reclaimable inodes and mark them with I_FREEING flag at first, at that
time, other processes will be stuck if they try getting these inodes
(See function find_inode_fast), then the reclaiming process destroy the
inodes by function dispose_list(). Some filesystems(eg. ext4 with
ea_inode feature, ubifs with xattr) may do inode lookup in the inode
evicting callback function, if the inode lookup is operated under the
inode lru traversing context, deadlock problems may happen.
Case 1: In function ext4_evict_inode(), the ea inode lookup could happen
if ea_inode feature is enabled, the lookup process will be stuck
under the evicting context like this:
1. File A has inode i_reg and an ea inode i_ea
2. getfattr(A, xattr_buf) // i_ea is added into lru // lru->i_ea
3. Then, following three processes running like this:
PA PB
echo 2 > /proc/sys/vm/drop_caches
shrink_slab
prune_dcache_sb
// i_reg is added into lru, lru->i_ea->i_reg
prune_icache_sb
list_lru_walk_one
inode_lru_isolate
i_ea->i_state |= I_FREEING // set inode state
inode_lru_isolate
__iget(i_reg)
spin_unlock(&i_reg->i_lock)
spin_unlock(lru_lock)
rm file A
i_reg->nlink = 0
iput(i_reg) // i_reg->nlink is 0, do evict
ext4_evict_inode
ext4_xattr_delete_inode
ext4_xattr_inode_dec_ref_all
ext4_xattr_inode_iget
ext4_iget(i_ea->i_ino)
iget_locked
find_inode_fast
__wait_on_freeing_inode(i_ea) ----→ AA deadlock
dispose_list // cannot be executed by prune_icache_sb
wake_up_bit(&i_ea->i_state)
Case 2: In deleted inode writing function ubifs_jnl_write_inode(), file
deleting process holds BASEHD's wbuf->io_mutex while getting the
xattr inode, which could race with inode reclaiming process(The
reclaiming process could try locking BASEHD's wbuf->io_mutex in
inode evicting function), then an ABBA deadlock problem would
happen as following:
1. File A has inode ia and a xattr(with inode ixa), regular file B has
inode ib and a xattr.
2. getfattr(A, xattr_buf) // ixa is added into lru // lru->ixa
3. Then, following three processes running like this:
PA PB PC
echo 2 > /proc/sys/vm/drop_caches
shrink_slab
prune_dcache_sb
// ib and ia are added into lru, lru->ixa->ib->ia
prune_icache_sb
list_lru_walk_one
inode_lru_isolate
ixa->i_state |= I_FREEING // set inode state
inode_lru_isolate
__iget(ib)
spin_unlock(&ib->i_lock)
spin_unlock(lru_lock)
rm file B
ib->nlink = 0
rm file A
iput(ia)
ubifs_evict_inode(ia)
ubifs_jnl_delete_inode(ia)
ubifs_jnl_write_inode(ia)
make_reservation(BASEHD) // Lock wbuf->io_mutex
ubifs_iget(ixa->i_ino)
iget_locked
find_inode_fast
__wait_on_freeing_inode(ixa)
| iput(ib) // ib->nlink is 0, do evict
| ubifs_evict_inode
| ubifs_jnl_delete_inode(ib)
↓ ubifs_jnl_write_inode
ABBA deadlock ←-----make_reservation(BASEHD)
dispose_list // cannot be executed by prune_icache_sb
wake_up_bit(&ixa->i_state)
Fix the possible deadlock by using new inode state flag I_LRU_ISOLATING
to pin the inode in memory while inode_lru_isolate() reclaims its pages
instead of using ordinary inode reference. This way inode deletion
cannot be triggered from inode_lru_isolate() thus avoiding the deadlock.
evict() is made to wait for I_LRU_ISOLATING to be cleared before
proceeding with inode cleanup.
Link: https://lore.kernel.org/all/37c29c42-7685-d1f0-067d-63582ffac405@huaweicloud.com/
Link: https://bugzilla.kernel.org/show_bug.cgi?id=219022
Fixes: e50e5129f384 ("ext4: xattr-in-inode support")
Fixes: 7959cf3a7506 ("ubifs: journal: Handle xattrs like files")
Cc: stable@vger.kernel.org
Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
Link: https://lore.kernel.org/r/20240809031628.1069873-1-chengzhihao@huaweicloud.com
Reviewed-by: Jan Kara <jack@suse.cz>
Suggested-by: Jan Kara <jack@suse.cz>
Suggested-by: Mateusz Guzik <mjguzik@gmail.com>
Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-08-09 03:16:28 +00:00
|
|
|
spin_unlock(&inode->i_lock);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void inode_wait_for_lru_isolating(struct inode *inode)
|
|
|
|
{
|
2024-08-23 12:47:39 +00:00
|
|
|
struct wait_bit_queue_entry wqe;
|
|
|
|
struct wait_queue_head *wq_head;
|
|
|
|
|
2024-08-13 14:36:26 +00:00
|
|
|
lockdep_assert_held(&inode->i_lock);
|
2024-08-23 12:47:39 +00:00
|
|
|
if (!(inode->i_state & I_LRU_ISOLATING))
|
|
|
|
return;
|
vfs: Don't evict inode under the inode lru traversing context
The inode reclaiming process(See function prune_icache_sb) collects all
reclaimable inodes and mark them with I_FREEING flag at first, at that
time, other processes will be stuck if they try getting these inodes
(See function find_inode_fast), then the reclaiming process destroy the
inodes by function dispose_list(). Some filesystems(eg. ext4 with
ea_inode feature, ubifs with xattr) may do inode lookup in the inode
evicting callback function, if the inode lookup is operated under the
inode lru traversing context, deadlock problems may happen.
Case 1: In function ext4_evict_inode(), the ea inode lookup could happen
if ea_inode feature is enabled, the lookup process will be stuck
under the evicting context like this:
1. File A has inode i_reg and an ea inode i_ea
2. getfattr(A, xattr_buf) // i_ea is added into lru // lru->i_ea
3. Then, following three processes running like this:
PA PB
echo 2 > /proc/sys/vm/drop_caches
shrink_slab
prune_dcache_sb
// i_reg is added into lru, lru->i_ea->i_reg
prune_icache_sb
list_lru_walk_one
inode_lru_isolate
i_ea->i_state |= I_FREEING // set inode state
inode_lru_isolate
__iget(i_reg)
spin_unlock(&i_reg->i_lock)
spin_unlock(lru_lock)
rm file A
i_reg->nlink = 0
iput(i_reg) // i_reg->nlink is 0, do evict
ext4_evict_inode
ext4_xattr_delete_inode
ext4_xattr_inode_dec_ref_all
ext4_xattr_inode_iget
ext4_iget(i_ea->i_ino)
iget_locked
find_inode_fast
__wait_on_freeing_inode(i_ea) ----→ AA deadlock
dispose_list // cannot be executed by prune_icache_sb
wake_up_bit(&i_ea->i_state)
Case 2: In deleted inode writing function ubifs_jnl_write_inode(), file
deleting process holds BASEHD's wbuf->io_mutex while getting the
xattr inode, which could race with inode reclaiming process(The
reclaiming process could try locking BASEHD's wbuf->io_mutex in
inode evicting function), then an ABBA deadlock problem would
happen as following:
1. File A has inode ia and a xattr(with inode ixa), regular file B has
inode ib and a xattr.
2. getfattr(A, xattr_buf) // ixa is added into lru // lru->ixa
3. Then, following three processes running like this:
PA PB PC
echo 2 > /proc/sys/vm/drop_caches
shrink_slab
prune_dcache_sb
// ib and ia are added into lru, lru->ixa->ib->ia
prune_icache_sb
list_lru_walk_one
inode_lru_isolate
ixa->i_state |= I_FREEING // set inode state
inode_lru_isolate
__iget(ib)
spin_unlock(&ib->i_lock)
spin_unlock(lru_lock)
rm file B
ib->nlink = 0
rm file A
iput(ia)
ubifs_evict_inode(ia)
ubifs_jnl_delete_inode(ia)
ubifs_jnl_write_inode(ia)
make_reservation(BASEHD) // Lock wbuf->io_mutex
ubifs_iget(ixa->i_ino)
iget_locked
find_inode_fast
__wait_on_freeing_inode(ixa)
| iput(ib) // ib->nlink is 0, do evict
| ubifs_evict_inode
| ubifs_jnl_delete_inode(ib)
↓ ubifs_jnl_write_inode
ABBA deadlock ←-----make_reservation(BASEHD)
dispose_list // cannot be executed by prune_icache_sb
wake_up_bit(&ixa->i_state)
Fix the possible deadlock by using new inode state flag I_LRU_ISOLATING
to pin the inode in memory while inode_lru_isolate() reclaims its pages
instead of using ordinary inode reference. This way inode deletion
cannot be triggered from inode_lru_isolate() thus avoiding the deadlock.
evict() is made to wait for I_LRU_ISOLATING to be cleared before
proceeding with inode cleanup.
Link: https://lore.kernel.org/all/37c29c42-7685-d1f0-067d-63582ffac405@huaweicloud.com/
Link: https://bugzilla.kernel.org/show_bug.cgi?id=219022
Fixes: e50e5129f384 ("ext4: xattr-in-inode support")
Fixes: 7959cf3a7506 ("ubifs: journal: Handle xattrs like files")
Cc: stable@vger.kernel.org
Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
Link: https://lore.kernel.org/r/20240809031628.1069873-1-chengzhihao@huaweicloud.com
Reviewed-by: Jan Kara <jack@suse.cz>
Suggested-by: Jan Kara <jack@suse.cz>
Suggested-by: Mateusz Guzik <mjguzik@gmail.com>
Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-08-09 03:16:28 +00:00
|
|
|
|
2024-08-23 12:47:39 +00:00
|
|
|
wq_head = inode_bit_waitqueue(&wqe, inode, __I_LRU_ISOLATING);
|
|
|
|
for (;;) {
|
|
|
|
prepare_to_wait_event(wq_head, &wqe.wq_entry, TASK_UNINTERRUPTIBLE);
|
|
|
|
/*
|
|
|
|
* Checking I_LRU_ISOLATING with inode->i_lock guarantees
|
|
|
|
* memory ordering.
|
|
|
|
*/
|
|
|
|
if (!(inode->i_state & I_LRU_ISOLATING))
|
|
|
|
break;
|
vfs: Don't evict inode under the inode lru traversing context
The inode reclaiming process(See function prune_icache_sb) collects all
reclaimable inodes and mark them with I_FREEING flag at first, at that
time, other processes will be stuck if they try getting these inodes
(See function find_inode_fast), then the reclaiming process destroy the
inodes by function dispose_list(). Some filesystems(eg. ext4 with
ea_inode feature, ubifs with xattr) may do inode lookup in the inode
evicting callback function, if the inode lookup is operated under the
inode lru traversing context, deadlock problems may happen.
Case 1: In function ext4_evict_inode(), the ea inode lookup could happen
if ea_inode feature is enabled, the lookup process will be stuck
under the evicting context like this:
1. File A has inode i_reg and an ea inode i_ea
2. getfattr(A, xattr_buf) // i_ea is added into lru // lru->i_ea
3. Then, following three processes running like this:
PA PB
echo 2 > /proc/sys/vm/drop_caches
shrink_slab
prune_dcache_sb
// i_reg is added into lru, lru->i_ea->i_reg
prune_icache_sb
list_lru_walk_one
inode_lru_isolate
i_ea->i_state |= I_FREEING // set inode state
inode_lru_isolate
__iget(i_reg)
spin_unlock(&i_reg->i_lock)
spin_unlock(lru_lock)
rm file A
i_reg->nlink = 0
iput(i_reg) // i_reg->nlink is 0, do evict
ext4_evict_inode
ext4_xattr_delete_inode
ext4_xattr_inode_dec_ref_all
ext4_xattr_inode_iget
ext4_iget(i_ea->i_ino)
iget_locked
find_inode_fast
__wait_on_freeing_inode(i_ea) ----→ AA deadlock
dispose_list // cannot be executed by prune_icache_sb
wake_up_bit(&i_ea->i_state)
Case 2: In deleted inode writing function ubifs_jnl_write_inode(), file
deleting process holds BASEHD's wbuf->io_mutex while getting the
xattr inode, which could race with inode reclaiming process(The
reclaiming process could try locking BASEHD's wbuf->io_mutex in
inode evicting function), then an ABBA deadlock problem would
happen as following:
1. File A has inode ia and a xattr(with inode ixa), regular file B has
inode ib and a xattr.
2. getfattr(A, xattr_buf) // ixa is added into lru // lru->ixa
3. Then, following three processes running like this:
PA PB PC
echo 2 > /proc/sys/vm/drop_caches
shrink_slab
prune_dcache_sb
// ib and ia are added into lru, lru->ixa->ib->ia
prune_icache_sb
list_lru_walk_one
inode_lru_isolate
ixa->i_state |= I_FREEING // set inode state
inode_lru_isolate
__iget(ib)
spin_unlock(&ib->i_lock)
spin_unlock(lru_lock)
rm file B
ib->nlink = 0
rm file A
iput(ia)
ubifs_evict_inode(ia)
ubifs_jnl_delete_inode(ia)
ubifs_jnl_write_inode(ia)
make_reservation(BASEHD) // Lock wbuf->io_mutex
ubifs_iget(ixa->i_ino)
iget_locked
find_inode_fast
__wait_on_freeing_inode(ixa)
| iput(ib) // ib->nlink is 0, do evict
| ubifs_evict_inode
| ubifs_jnl_delete_inode(ib)
↓ ubifs_jnl_write_inode
ABBA deadlock ←-----make_reservation(BASEHD)
dispose_list // cannot be executed by prune_icache_sb
wake_up_bit(&ixa->i_state)
Fix the possible deadlock by using new inode state flag I_LRU_ISOLATING
to pin the inode in memory while inode_lru_isolate() reclaims its pages
instead of using ordinary inode reference. This way inode deletion
cannot be triggered from inode_lru_isolate() thus avoiding the deadlock.
evict() is made to wait for I_LRU_ISOLATING to be cleared before
proceeding with inode cleanup.
Link: https://lore.kernel.org/all/37c29c42-7685-d1f0-067d-63582ffac405@huaweicloud.com/
Link: https://bugzilla.kernel.org/show_bug.cgi?id=219022
Fixes: e50e5129f384 ("ext4: xattr-in-inode support")
Fixes: 7959cf3a7506 ("ubifs: journal: Handle xattrs like files")
Cc: stable@vger.kernel.org
Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
Link: https://lore.kernel.org/r/20240809031628.1069873-1-chengzhihao@huaweicloud.com
Reviewed-by: Jan Kara <jack@suse.cz>
Suggested-by: Jan Kara <jack@suse.cz>
Suggested-by: Mateusz Guzik <mjguzik@gmail.com>
Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-08-09 03:16:28 +00:00
|
|
|
spin_unlock(&inode->i_lock);
|
2024-08-23 12:47:39 +00:00
|
|
|
schedule();
|
vfs: Don't evict inode under the inode lru traversing context
The inode reclaiming process(See function prune_icache_sb) collects all
reclaimable inodes and mark them with I_FREEING flag at first, at that
time, other processes will be stuck if they try getting these inodes
(See function find_inode_fast), then the reclaiming process destroy the
inodes by function dispose_list(). Some filesystems(eg. ext4 with
ea_inode feature, ubifs with xattr) may do inode lookup in the inode
evicting callback function, if the inode lookup is operated under the
inode lru traversing context, deadlock problems may happen.
Case 1: In function ext4_evict_inode(), the ea inode lookup could happen
if ea_inode feature is enabled, the lookup process will be stuck
under the evicting context like this:
1. File A has inode i_reg and an ea inode i_ea
2. getfattr(A, xattr_buf) // i_ea is added into lru // lru->i_ea
3. Then, following three processes running like this:
PA PB
echo 2 > /proc/sys/vm/drop_caches
shrink_slab
prune_dcache_sb
// i_reg is added into lru, lru->i_ea->i_reg
prune_icache_sb
list_lru_walk_one
inode_lru_isolate
i_ea->i_state |= I_FREEING // set inode state
inode_lru_isolate
__iget(i_reg)
spin_unlock(&i_reg->i_lock)
spin_unlock(lru_lock)
rm file A
i_reg->nlink = 0
iput(i_reg) // i_reg->nlink is 0, do evict
ext4_evict_inode
ext4_xattr_delete_inode
ext4_xattr_inode_dec_ref_all
ext4_xattr_inode_iget
ext4_iget(i_ea->i_ino)
iget_locked
find_inode_fast
__wait_on_freeing_inode(i_ea) ----→ AA deadlock
dispose_list // cannot be executed by prune_icache_sb
wake_up_bit(&i_ea->i_state)
Case 2: In deleted inode writing function ubifs_jnl_write_inode(), file
deleting process holds BASEHD's wbuf->io_mutex while getting the
xattr inode, which could race with inode reclaiming process(The
reclaiming process could try locking BASEHD's wbuf->io_mutex in
inode evicting function), then an ABBA deadlock problem would
happen as following:
1. File A has inode ia and a xattr(with inode ixa), regular file B has
inode ib and a xattr.
2. getfattr(A, xattr_buf) // ixa is added into lru // lru->ixa
3. Then, following three processes running like this:
PA PB PC
echo 2 > /proc/sys/vm/drop_caches
shrink_slab
prune_dcache_sb
// ib and ia are added into lru, lru->ixa->ib->ia
prune_icache_sb
list_lru_walk_one
inode_lru_isolate
ixa->i_state |= I_FREEING // set inode state
inode_lru_isolate
__iget(ib)
spin_unlock(&ib->i_lock)
spin_unlock(lru_lock)
rm file B
ib->nlink = 0
rm file A
iput(ia)
ubifs_evict_inode(ia)
ubifs_jnl_delete_inode(ia)
ubifs_jnl_write_inode(ia)
make_reservation(BASEHD) // Lock wbuf->io_mutex
ubifs_iget(ixa->i_ino)
iget_locked
find_inode_fast
__wait_on_freeing_inode(ixa)
| iput(ib) // ib->nlink is 0, do evict
| ubifs_evict_inode
| ubifs_jnl_delete_inode(ib)
↓ ubifs_jnl_write_inode
ABBA deadlock ←-----make_reservation(BASEHD)
dispose_list // cannot be executed by prune_icache_sb
wake_up_bit(&ixa->i_state)
Fix the possible deadlock by using new inode state flag I_LRU_ISOLATING
to pin the inode in memory while inode_lru_isolate() reclaims its pages
instead of using ordinary inode reference. This way inode deletion
cannot be triggered from inode_lru_isolate() thus avoiding the deadlock.
evict() is made to wait for I_LRU_ISOLATING to be cleared before
proceeding with inode cleanup.
Link: https://lore.kernel.org/all/37c29c42-7685-d1f0-067d-63582ffac405@huaweicloud.com/
Link: https://bugzilla.kernel.org/show_bug.cgi?id=219022
Fixes: e50e5129f384 ("ext4: xattr-in-inode support")
Fixes: 7959cf3a7506 ("ubifs: journal: Handle xattrs like files")
Cc: stable@vger.kernel.org
Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
Link: https://lore.kernel.org/r/20240809031628.1069873-1-chengzhihao@huaweicloud.com
Reviewed-by: Jan Kara <jack@suse.cz>
Suggested-by: Jan Kara <jack@suse.cz>
Suggested-by: Mateusz Guzik <mjguzik@gmail.com>
Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-08-09 03:16:28 +00:00
|
|
|
spin_lock(&inode->i_lock);
|
|
|
|
}
|
2024-08-23 12:47:39 +00:00
|
|
|
finish_wait(wq_head, &wqe.wq_entry);
|
|
|
|
WARN_ON(inode->i_state & I_LRU_ISOLATING);
|
vfs: Don't evict inode under the inode lru traversing context
The inode reclaiming process(See function prune_icache_sb) collects all
reclaimable inodes and mark them with I_FREEING flag at first, at that
time, other processes will be stuck if they try getting these inodes
(See function find_inode_fast), then the reclaiming process destroy the
inodes by function dispose_list(). Some filesystems(eg. ext4 with
ea_inode feature, ubifs with xattr) may do inode lookup in the inode
evicting callback function, if the inode lookup is operated under the
inode lru traversing context, deadlock problems may happen.
Case 1: In function ext4_evict_inode(), the ea inode lookup could happen
if ea_inode feature is enabled, the lookup process will be stuck
under the evicting context like this:
1. File A has inode i_reg and an ea inode i_ea
2. getfattr(A, xattr_buf) // i_ea is added into lru // lru->i_ea
3. Then, following three processes running like this:
PA PB
echo 2 > /proc/sys/vm/drop_caches
shrink_slab
prune_dcache_sb
// i_reg is added into lru, lru->i_ea->i_reg
prune_icache_sb
list_lru_walk_one
inode_lru_isolate
i_ea->i_state |= I_FREEING // set inode state
inode_lru_isolate
__iget(i_reg)
spin_unlock(&i_reg->i_lock)
spin_unlock(lru_lock)
rm file A
i_reg->nlink = 0
iput(i_reg) // i_reg->nlink is 0, do evict
ext4_evict_inode
ext4_xattr_delete_inode
ext4_xattr_inode_dec_ref_all
ext4_xattr_inode_iget
ext4_iget(i_ea->i_ino)
iget_locked
find_inode_fast
__wait_on_freeing_inode(i_ea) ----→ AA deadlock
dispose_list // cannot be executed by prune_icache_sb
wake_up_bit(&i_ea->i_state)
Case 2: In deleted inode writing function ubifs_jnl_write_inode(), file
deleting process holds BASEHD's wbuf->io_mutex while getting the
xattr inode, which could race with inode reclaiming process(The
reclaiming process could try locking BASEHD's wbuf->io_mutex in
inode evicting function), then an ABBA deadlock problem would
happen as following:
1. File A has inode ia and a xattr(with inode ixa), regular file B has
inode ib and a xattr.
2. getfattr(A, xattr_buf) // ixa is added into lru // lru->ixa
3. Then, following three processes running like this:
PA PB PC
echo 2 > /proc/sys/vm/drop_caches
shrink_slab
prune_dcache_sb
// ib and ia are added into lru, lru->ixa->ib->ia
prune_icache_sb
list_lru_walk_one
inode_lru_isolate
ixa->i_state |= I_FREEING // set inode state
inode_lru_isolate
__iget(ib)
spin_unlock(&ib->i_lock)
spin_unlock(lru_lock)
rm file B
ib->nlink = 0
rm file A
iput(ia)
ubifs_evict_inode(ia)
ubifs_jnl_delete_inode(ia)
ubifs_jnl_write_inode(ia)
make_reservation(BASEHD) // Lock wbuf->io_mutex
ubifs_iget(ixa->i_ino)
iget_locked
find_inode_fast
__wait_on_freeing_inode(ixa)
| iput(ib) // ib->nlink is 0, do evict
| ubifs_evict_inode
| ubifs_jnl_delete_inode(ib)
↓ ubifs_jnl_write_inode
ABBA deadlock ←-----make_reservation(BASEHD)
dispose_list // cannot be executed by prune_icache_sb
wake_up_bit(&ixa->i_state)
Fix the possible deadlock by using new inode state flag I_LRU_ISOLATING
to pin the inode in memory while inode_lru_isolate() reclaims its pages
instead of using ordinary inode reference. This way inode deletion
cannot be triggered from inode_lru_isolate() thus avoiding the deadlock.
evict() is made to wait for I_LRU_ISOLATING to be cleared before
proceeding with inode cleanup.
Link: https://lore.kernel.org/all/37c29c42-7685-d1f0-067d-63582ffac405@huaweicloud.com/
Link: https://bugzilla.kernel.org/show_bug.cgi?id=219022
Fixes: e50e5129f384 ("ext4: xattr-in-inode support")
Fixes: 7959cf3a7506 ("ubifs: journal: Handle xattrs like files")
Cc: stable@vger.kernel.org
Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
Link: https://lore.kernel.org/r/20240809031628.1069873-1-chengzhihao@huaweicloud.com
Reviewed-by: Jan Kara <jack@suse.cz>
Suggested-by: Jan Kara <jack@suse.cz>
Suggested-by: Mateusz Guzik <mjguzik@gmail.com>
Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-08-09 03:16:28 +00:00
|
|
|
}
|
|
|
|
|
2010-10-23 11:15:32 +00:00
|
|
|
/**
|
|
|
|
* inode_sb_list_add - add inode to the superblock list of inodes
|
|
|
|
* @inode: inode to add
|
|
|
|
*/
|
|
|
|
void inode_sb_list_add(struct inode *inode)
|
|
|
|
{
|
2015-03-04 17:37:22 +00:00
|
|
|
spin_lock(&inode->i_sb->s_inode_list_lock);
|
2011-03-22 11:23:40 +00:00
|
|
|
list_add(&inode->i_sb_list, &inode->i_sb->s_inodes);
|
2015-03-04 17:37:22 +00:00
|
|
|
spin_unlock(&inode->i_sb->s_inode_list_lock);
|
2010-10-23 11:15:32 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(inode_sb_list_add);
|
|
|
|
|
2011-03-22 11:23:40 +00:00
|
|
|
static inline void inode_sb_list_del(struct inode *inode)
|
2010-10-23 11:15:32 +00:00
|
|
|
{
|
2011-07-26 09:36:34 +00:00
|
|
|
if (!list_empty(&inode->i_sb_list)) {
|
2015-03-04 17:37:22 +00:00
|
|
|
spin_lock(&inode->i_sb->s_inode_list_lock);
|
2011-07-26 09:36:34 +00:00
|
|
|
list_del_init(&inode->i_sb_list);
|
2015-03-04 17:37:22 +00:00
|
|
|
spin_unlock(&inode->i_sb->s_inode_list_lock);
|
2011-07-26 09:36:34 +00:00
|
|
|
}
|
2010-10-23 11:15:32 +00:00
|
|
|
}
|
|
|
|
|
2010-10-23 10:58:09 +00:00
|
|
|
static unsigned long hash(struct super_block *sb, unsigned long hashval)
|
|
|
|
{
|
|
|
|
unsigned long tmp;
|
|
|
|
|
|
|
|
tmp = (hashval * (unsigned long)sb) ^ (GOLDEN_RATIO_PRIME + hashval) /
|
|
|
|
L1_CACHE_BYTES;
|
2011-05-27 13:28:01 +00:00
|
|
|
tmp = tmp ^ ((tmp ^ GOLDEN_RATIO_PRIME) >> i_hash_shift);
|
|
|
|
return tmp & i_hash_mask;
|
2010-10-23 10:58:09 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* __insert_inode_hash - hash an inode
|
|
|
|
* @inode: unhashed inode
|
|
|
|
* @hashval: unsigned long value used to locate this object in the
|
|
|
|
* inode_hashtable.
|
|
|
|
*
|
|
|
|
* Add an inode to the inode hash for this superblock.
|
|
|
|
*/
|
|
|
|
void __insert_inode_hash(struct inode *inode, unsigned long hashval)
|
|
|
|
{
|
2010-10-23 11:15:32 +00:00
|
|
|
struct hlist_head *b = inode_hashtable + hash(inode->i_sb, hashval);
|
|
|
|
|
2011-03-22 11:23:42 +00:00
|
|
|
spin_lock(&inode_hash_lock);
|
2011-03-22 11:23:36 +00:00
|
|
|
spin_lock(&inode->i_lock);
|
2017-12-01 11:40:16 +00:00
|
|
|
hlist_add_head_rcu(&inode->i_hash, b);
|
2011-03-22 11:23:36 +00:00
|
|
|
spin_unlock(&inode->i_lock);
|
2011-03-22 11:23:42 +00:00
|
|
|
spin_unlock(&inode_hash_lock);
|
2010-10-23 10:58:09 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(__insert_inode_hash);
|
|
|
|
|
|
|
|
/**
|
2011-07-28 04:41:09 +00:00
|
|
|
* __remove_inode_hash - remove an inode from the hash
|
2010-10-23 10:58:09 +00:00
|
|
|
* @inode: inode to unhash
|
|
|
|
*
|
|
|
|
* Remove an inode from the superblock.
|
|
|
|
*/
|
2011-07-28 04:41:09 +00:00
|
|
|
void __remove_inode_hash(struct inode *inode)
|
2010-10-23 10:58:09 +00:00
|
|
|
{
|
2011-03-22 11:23:42 +00:00
|
|
|
spin_lock(&inode_hash_lock);
|
2011-03-22 11:23:36 +00:00
|
|
|
spin_lock(&inode->i_lock);
|
2017-12-01 11:40:16 +00:00
|
|
|
hlist_del_init_rcu(&inode->i_hash);
|
2011-03-22 11:23:36 +00:00
|
|
|
spin_unlock(&inode->i_lock);
|
2011-03-22 11:23:42 +00:00
|
|
|
spin_unlock(&inode_hash_lock);
|
2010-10-23 10:58:09 +00:00
|
|
|
}
|
2011-07-28 04:41:09 +00:00
|
|
|
EXPORT_SYMBOL(__remove_inode_hash);
|
2010-10-23 10:58:09 +00:00
|
|
|
|
2022-01-14 22:05:04 +00:00
|
|
|
void dump_mapping(const struct address_space *mapping)
|
|
|
|
{
|
|
|
|
struct inode *host;
|
|
|
|
const struct address_space_operations *a_ops;
|
|
|
|
struct hlist_node *dentry_first;
|
|
|
|
struct dentry *dentry_ptr;
|
|
|
|
struct dentry dentry;
|
2024-08-26 05:55:03 +00:00
|
|
|
char fname[64] = {};
|
2022-01-14 22:05:04 +00:00
|
|
|
unsigned long ino;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If mapping is an invalid pointer, we don't want to crash
|
|
|
|
* accessing it, so probe everything depending on it carefully.
|
|
|
|
*/
|
|
|
|
if (get_kernel_nofault(host, &mapping->host) ||
|
|
|
|
get_kernel_nofault(a_ops, &mapping->a_ops)) {
|
|
|
|
pr_warn("invalid mapping:%px\n", mapping);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!host) {
|
|
|
|
pr_warn("aops:%ps\n", a_ops);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (get_kernel_nofault(dentry_first, &host->i_dentry.first) ||
|
|
|
|
get_kernel_nofault(ino, &host->i_ino)) {
|
|
|
|
pr_warn("aops:%ps invalid inode:%px\n", a_ops, host);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!dentry_first) {
|
|
|
|
pr_warn("aops:%ps ino:%lx\n", a_ops, ino);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
dentry_ptr = container_of(dentry_first, struct dentry, d_u.d_alias);
|
fs: improve dump_mapping() robustness
We met a kernel crash issue when running stress-ng testing, and the
system crashes when printing the dentry name in dump_mapping().
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
pc : dentry_name+0xd8/0x224
lr : pointer+0x22c/0x370
sp : ffff800025f134c0
......
Call trace:
dentry_name+0xd8/0x224
pointer+0x22c/0x370
vsnprintf+0x1ec/0x730
vscnprintf+0x2c/0x60
vprintk_store+0x70/0x234
vprintk_emit+0xe0/0x24c
vprintk_default+0x3c/0x44
vprintk_func+0x84/0x2d0
printk+0x64/0x88
__dump_page+0x52c/0x530
dump_page+0x14/0x20
set_migratetype_isolate+0x110/0x224
start_isolate_page_range+0xc4/0x20c
offline_pages+0x124/0x474
memory_block_offline+0x44/0xf4
memory_subsys_offline+0x3c/0x70
device_offline+0xf0/0x120
......
The root cause is that, one thread is doing page migration, and we will
use the target page's ->mapping field to save 'anon_vma' pointer between
page unmap and page move, and now the target page is locked and refcount
is 1.
Currently, there is another stress-ng thread performing memory hotplug,
attempting to offline the target page that is being migrated. It discovers
that the refcount of this target page is 1, preventing the offline operation,
thus proceeding to dump the page. However, page_mapping() of the target
page may return an incorrect file mapping to crash the system in dump_mapping(),
since the target page->mapping only saves 'anon_vma' pointer without setting
PAGE_MAPPING_ANON flag.
The page migration issue has been fixed by commit d1adb25df711 ("mm: migrate:
fix getting incorrect page mapping during page migration"). In addition,
Matthew suggested we should also improve dump_mapping()'s robustness to
resilient against the kernel crash [1].
With checking the 'dentry.parent' and 'dentry.d_name.name' used by
dentry_name(), I can see dump_mapping() will output the invalid dentry
instead of crashing the system when this issue is reproduced again.
[12211.189128] page:fffff7de047741c0 refcount:1 mapcount:0 mapping:ffff989117f55ea0 index:0x1 pfn:0x211dd07
[12211.189144] aops:0x0 ino:1 invalid dentry:74786574206e6870
[12211.189148] flags: 0x57ffffc0000001(locked|node=1|zone=2|lastcpupid=0x1fffff)
[12211.189150] page_type: 0xffffffff()
[12211.189153] raw: 0057ffffc0000001 0000000000000000 dead000000000122 ffff989117f55ea0
[12211.189154] raw: 0000000000000001 0000000000000001 00000001ffffffff 0000000000000000
[12211.189155] page dumped because: unmovable page
[1] https://lore.kernel.org/all/ZXxn%2F0oixJxxAnpF@casper.infradead.org/
Suggested-by: Matthew Wilcox <willy@infradead.org>
Signed-off-by: Baolin Wang <baolin.wang@linux.alibaba.com>
Link: https://lore.kernel.org/r/937ab1f87328516821d39be672b6bc18861d9d3e.1705391420.git.baolin.wang@linux.alibaba.com
Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-01-16 07:53:35 +00:00
|
|
|
if (get_kernel_nofault(dentry, dentry_ptr) ||
|
|
|
|
!dentry.d_parent || !dentry.d_name.name) {
|
2022-01-14 22:05:04 +00:00
|
|
|
pr_warn("aops:%ps ino:%lx invalid dentry:%px\n",
|
|
|
|
a_ops, ino, dentry_ptr);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2024-08-26 05:55:03 +00:00
|
|
|
if (strncpy_from_kernel_nofault(fname, dentry.d_name.name, 63) < 0)
|
|
|
|
strscpy(fname, "<invalid>");
|
2022-01-14 22:05:04 +00:00
|
|
|
/*
|
2024-08-26 05:55:03 +00:00
|
|
|
* Even if strncpy_from_kernel_nofault() succeeded,
|
|
|
|
* the fname could be unreliable
|
2022-01-14 22:05:04 +00:00
|
|
|
*/
|
2024-08-26 05:55:03 +00:00
|
|
|
pr_warn("aops:%ps ino:%lx dentry name(?):\"%s\"\n",
|
|
|
|
a_ops, ino, fname);
|
2022-01-14 22:05:04 +00:00
|
|
|
}
|
|
|
|
|
2012-05-03 12:48:02 +00:00
|
|
|
void clear_inode(struct inode *inode)
|
2010-06-05 00:55:25 +00:00
|
|
|
{
|
2011-06-27 23:18:10 +00:00
|
|
|
/*
|
2018-04-10 23:36:56 +00:00
|
|
|
* We have to cycle the i_pages lock here because reclaim can be in the
|
2022-06-29 00:41:40 +00:00
|
|
|
* process of removing the last page (in __filemap_remove_folio())
|
2018-04-10 23:36:56 +00:00
|
|
|
* and we must not free the mapping under it.
|
2011-06-27 23:18:10 +00:00
|
|
|
*/
|
2018-04-10 23:36:56 +00:00
|
|
|
xa_lock_irq(&inode->i_data.i_pages);
|
2010-06-05 00:55:25 +00:00
|
|
|
BUG_ON(inode->i_data.nrpages);
|
2021-05-05 01:32:57 +00:00
|
|
|
/*
|
|
|
|
* Almost always, mapping_empty(&inode->i_data) here; but there are
|
|
|
|
* two known and long-standing ways in which nodes may get left behind
|
|
|
|
* (when deep radix-tree node allocation failed partway; or when THP
|
|
|
|
* collapse_file() failed). Until those two known cases are cleaned up,
|
|
|
|
* or a cleanup function is called here, do not BUG_ON(!mapping_empty),
|
|
|
|
* nor even WARN_ON(!mapping_empty).
|
|
|
|
*/
|
2018-04-10 23:36:56 +00:00
|
|
|
xa_unlock_irq(&inode->i_data.i_pages);
|
2023-11-17 21:58:23 +00:00
|
|
|
BUG_ON(!list_empty(&inode->i_data.i_private_list));
|
2010-06-05 00:55:25 +00:00
|
|
|
BUG_ON(!(inode->i_state & I_FREEING));
|
|
|
|
BUG_ON(inode->i_state & I_CLEAR);
|
2016-07-26 22:21:50 +00:00
|
|
|
BUG_ON(!list_empty(&inode->i_wb_list));
|
2011-01-07 06:49:49 +00:00
|
|
|
/* don't need i_lock here, no concurrent mods to i_state */
|
2010-06-05 00:55:25 +00:00
|
|
|
inode->i_state = I_FREEING | I_CLEAR;
|
|
|
|
}
|
2012-05-03 12:48:02 +00:00
|
|
|
EXPORT_SYMBOL(clear_inode);
|
2010-06-05 00:55:25 +00:00
|
|
|
|
2011-03-22 11:23:37 +00:00
|
|
|
/*
|
|
|
|
* Free the inode passed in, removing it from the lists it is still connected
|
|
|
|
* to. We remove any pages still attached to the inode and wait for any IO that
|
|
|
|
* is still in progress before finally destroying the inode.
|
|
|
|
*
|
|
|
|
* An inode must already be marked I_FREEING so that we avoid the inode being
|
|
|
|
* moved back onto lists if we race with other code that manipulates the lists
|
|
|
|
* (e.g. writeback_single_inode). The caller is responsible for setting this.
|
|
|
|
*
|
|
|
|
* An inode must already be removed from the LRU list before being evicted from
|
|
|
|
* the cache. This should occur atomically with setting the I_FREEING state
|
|
|
|
* flag, so no inodes here should ever be on the LRU when being evicted.
|
|
|
|
*/
|
2010-06-07 17:21:05 +00:00
|
|
|
static void evict(struct inode *inode)
|
2010-06-04 23:33:20 +00:00
|
|
|
{
|
|
|
|
const struct super_operations *op = inode->i_sb->s_op;
|
|
|
|
|
2011-03-22 11:23:37 +00:00
|
|
|
BUG_ON(!(inode->i_state & I_FREEING));
|
|
|
|
BUG_ON(!list_empty(&inode->i_lru));
|
|
|
|
|
2015-03-04 19:07:22 +00:00
|
|
|
if (!list_empty(&inode->i_io_list))
|
|
|
|
inode_io_list_del(inode);
|
2011-07-28 04:11:47 +00:00
|
|
|
|
2011-03-22 11:23:40 +00:00
|
|
|
inode_sb_list_del(inode);
|
|
|
|
|
2024-08-13 14:36:26 +00:00
|
|
|
spin_lock(&inode->i_lock);
|
vfs: Don't evict inode under the inode lru traversing context
The inode reclaiming process(See function prune_icache_sb) collects all
reclaimable inodes and mark them with I_FREEING flag at first, at that
time, other processes will be stuck if they try getting these inodes
(See function find_inode_fast), then the reclaiming process destroy the
inodes by function dispose_list(). Some filesystems(eg. ext4 with
ea_inode feature, ubifs with xattr) may do inode lookup in the inode
evicting callback function, if the inode lookup is operated under the
inode lru traversing context, deadlock problems may happen.
Case 1: In function ext4_evict_inode(), the ea inode lookup could happen
if ea_inode feature is enabled, the lookup process will be stuck
under the evicting context like this:
1. File A has inode i_reg and an ea inode i_ea
2. getfattr(A, xattr_buf) // i_ea is added into lru // lru->i_ea
3. Then, following three processes running like this:
PA PB
echo 2 > /proc/sys/vm/drop_caches
shrink_slab
prune_dcache_sb
// i_reg is added into lru, lru->i_ea->i_reg
prune_icache_sb
list_lru_walk_one
inode_lru_isolate
i_ea->i_state |= I_FREEING // set inode state
inode_lru_isolate
__iget(i_reg)
spin_unlock(&i_reg->i_lock)
spin_unlock(lru_lock)
rm file A
i_reg->nlink = 0
iput(i_reg) // i_reg->nlink is 0, do evict
ext4_evict_inode
ext4_xattr_delete_inode
ext4_xattr_inode_dec_ref_all
ext4_xattr_inode_iget
ext4_iget(i_ea->i_ino)
iget_locked
find_inode_fast
__wait_on_freeing_inode(i_ea) ----→ AA deadlock
dispose_list // cannot be executed by prune_icache_sb
wake_up_bit(&i_ea->i_state)
Case 2: In deleted inode writing function ubifs_jnl_write_inode(), file
deleting process holds BASEHD's wbuf->io_mutex while getting the
xattr inode, which could race with inode reclaiming process(The
reclaiming process could try locking BASEHD's wbuf->io_mutex in
inode evicting function), then an ABBA deadlock problem would
happen as following:
1. File A has inode ia and a xattr(with inode ixa), regular file B has
inode ib and a xattr.
2. getfattr(A, xattr_buf) // ixa is added into lru // lru->ixa
3. Then, following three processes running like this:
PA PB PC
echo 2 > /proc/sys/vm/drop_caches
shrink_slab
prune_dcache_sb
// ib and ia are added into lru, lru->ixa->ib->ia
prune_icache_sb
list_lru_walk_one
inode_lru_isolate
ixa->i_state |= I_FREEING // set inode state
inode_lru_isolate
__iget(ib)
spin_unlock(&ib->i_lock)
spin_unlock(lru_lock)
rm file B
ib->nlink = 0
rm file A
iput(ia)
ubifs_evict_inode(ia)
ubifs_jnl_delete_inode(ia)
ubifs_jnl_write_inode(ia)
make_reservation(BASEHD) // Lock wbuf->io_mutex
ubifs_iget(ixa->i_ino)
iget_locked
find_inode_fast
__wait_on_freeing_inode(ixa)
| iput(ib) // ib->nlink is 0, do evict
| ubifs_evict_inode
| ubifs_jnl_delete_inode(ib)
↓ ubifs_jnl_write_inode
ABBA deadlock ←-----make_reservation(BASEHD)
dispose_list // cannot be executed by prune_icache_sb
wake_up_bit(&ixa->i_state)
Fix the possible deadlock by using new inode state flag I_LRU_ISOLATING
to pin the inode in memory while inode_lru_isolate() reclaims its pages
instead of using ordinary inode reference. This way inode deletion
cannot be triggered from inode_lru_isolate() thus avoiding the deadlock.
evict() is made to wait for I_LRU_ISOLATING to be cleared before
proceeding with inode cleanup.
Link: https://lore.kernel.org/all/37c29c42-7685-d1f0-067d-63582ffac405@huaweicloud.com/
Link: https://bugzilla.kernel.org/show_bug.cgi?id=219022
Fixes: e50e5129f384 ("ext4: xattr-in-inode support")
Fixes: 7959cf3a7506 ("ubifs: journal: Handle xattrs like files")
Cc: stable@vger.kernel.org
Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
Link: https://lore.kernel.org/r/20240809031628.1069873-1-chengzhihao@huaweicloud.com
Reviewed-by: Jan Kara <jack@suse.cz>
Suggested-by: Jan Kara <jack@suse.cz>
Suggested-by: Mateusz Guzik <mjguzik@gmail.com>
Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-08-09 03:16:28 +00:00
|
|
|
inode_wait_for_lru_isolating(inode);
|
|
|
|
|
2012-05-03 12:48:03 +00:00
|
|
|
/*
|
|
|
|
* Wait for flusher thread to be done with the inode so that filesystem
|
|
|
|
* does not start destroying it while writeback is still running. Since
|
|
|
|
* the inode has I_FREEING set, flusher thread won't start new work on
|
|
|
|
* the inode. We just have to wait for running writeback to finish.
|
|
|
|
*/
|
|
|
|
inode_wait_for_writeback(inode);
|
2024-08-13 14:36:26 +00:00
|
|
|
spin_unlock(&inode->i_lock);
|
2012-05-03 12:48:01 +00:00
|
|
|
|
2010-06-04 23:40:39 +00:00
|
|
|
if (op->evict_inode) {
|
|
|
|
op->evict_inode(inode);
|
2010-06-04 23:33:20 +00:00
|
|
|
} else {
|
2014-04-03 21:47:49 +00:00
|
|
|
truncate_inode_pages_final(&inode->i_data);
|
2012-05-03 12:48:02 +00:00
|
|
|
clear_inode(inode);
|
2010-06-04 23:33:20 +00:00
|
|
|
}
|
2010-06-05 00:19:55 +00:00
|
|
|
if (S_ISCHR(inode->i_mode) && inode->i_cdev)
|
|
|
|
cd_forget(inode);
|
2011-03-22 11:23:37 +00:00
|
|
|
|
|
|
|
remove_inode_hash(inode);
|
|
|
|
|
2024-07-18 15:18:37 +00:00
|
|
|
/*
|
|
|
|
* Wake up waiters in __wait_on_freeing_inode().
|
|
|
|
*
|
|
|
|
* Lockless hash lookup may end up finding the inode before we removed
|
|
|
|
* it above, but only lock it *after* we are done with the wakeup below.
|
|
|
|
* In this case the potential waiter cannot safely block.
|
|
|
|
*
|
|
|
|
* The inode being unhashed after the call to remove_inode_hash() is
|
|
|
|
* used as an indicator whether blocking on it is safe.
|
|
|
|
*/
|
2011-03-22 11:23:37 +00:00
|
|
|
spin_lock(&inode->i_lock);
|
2024-08-23 12:47:38 +00:00
|
|
|
/*
|
|
|
|
* Pairs with the barrier in prepare_to_wait_event() to make sure
|
|
|
|
* ___wait_var_event() either sees the bit cleared or
|
|
|
|
* waitqueue_active() check in wake_up_var() sees the waiter.
|
|
|
|
*/
|
2024-11-13 15:51:03 +00:00
|
|
|
smp_mb__after_spinlock();
|
2024-08-23 12:47:38 +00:00
|
|
|
inode_wake_up_bit(inode, __I_NEW);
|
2011-03-22 11:23:37 +00:00
|
|
|
BUG_ON(inode->i_state != (I_FREEING | I_CLEAR));
|
|
|
|
spin_unlock(&inode->i_lock);
|
|
|
|
|
|
|
|
destroy_inode(inode);
|
2010-06-04 23:33:20 +00:00
|
|
|
}
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/*
|
|
|
|
* dispose_list - dispose of the contents of a local list
|
|
|
|
* @head: the head of the list to free
|
|
|
|
*
|
|
|
|
* Dispose-list gets a local list with local inodes in it, so it doesn't
|
|
|
|
* need to worry about list corruption and SMP locks.
|
|
|
|
*/
|
|
|
|
static void dispose_list(struct list_head *head)
|
|
|
|
{
|
|
|
|
while (!list_empty(head)) {
|
|
|
|
struct inode *inode;
|
|
|
|
|
2010-10-21 00:49:30 +00:00
|
|
|
inode = list_first_entry(head, struct inode, i_lru);
|
|
|
|
list_del_init(&inode->i_lru);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2010-06-07 17:21:05 +00:00
|
|
|
evict(inode);
|
2015-03-04 21:52:52 +00:00
|
|
|
cond_resched();
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-10-26 00:49:35 +00:00
|
|
|
/**
|
|
|
|
* evict_inodes - evict all evictable inodes for a superblock
|
|
|
|
* @sb: superblock to operate on
|
|
|
|
*
|
|
|
|
* Make sure that no inodes with zero refcount are retained. This is
|
2017-11-27 21:05:09 +00:00
|
|
|
* called by superblock shutdown after having SB_ACTIVE flag removed,
|
2010-10-26 00:49:35 +00:00
|
|
|
* so any inode reaching zero refcount during or after that call will
|
|
|
|
* be immediately evicted.
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
2010-10-26 00:49:35 +00:00
|
|
|
void evict_inodes(struct super_block *sb)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2010-10-26 00:49:35 +00:00
|
|
|
struct inode *inode, *next;
|
|
|
|
LIST_HEAD(dispose);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2015-03-04 21:52:52 +00:00
|
|
|
again:
|
2015-03-04 17:37:22 +00:00
|
|
|
spin_lock(&sb->s_inode_list_lock);
|
2010-10-26 00:49:35 +00:00
|
|
|
list_for_each_entry_safe(inode, next, &sb->s_inodes, i_sb_list) {
|
|
|
|
if (atomic_read(&inode->i_count))
|
2009-03-11 20:17:36 +00:00
|
|
|
continue;
|
2011-03-22 11:23:36 +00:00
|
|
|
|
|
|
|
spin_lock(&inode->i_lock);
|
vfs: fix race between evice_inodes() and find_inode()&iput()
Hi, all
Recently I noticed a bug[1] in btrfs, after digged it into
and I believe it'a race in vfs.
Let's assume there's a inode (ie ino 261) with i_count 1 is
called by iput(), and there's a concurrent thread calling
generic_shutdown_super().
cpu0: cpu1:
iput() // i_count is 1
->spin_lock(inode)
->dec i_count to 0
->iput_final() generic_shutdown_super()
->__inode_add_lru() ->evict_inodes()
// cause some reason[2] ->if (atomic_read(inode->i_count)) continue;
// return before // inode 261 passed the above check
// list_lru_add_obj() // and then schedule out
->spin_unlock()
// note here: the inode 261
// was still at sb list and hash list,
// and I_FREEING|I_WILL_FREE was not been set
btrfs_iget()
// after some function calls
->find_inode()
// found the above inode 261
->spin_lock(inode)
// check I_FREEING|I_WILL_FREE
// and passed
->__iget()
->spin_unlock(inode) // schedule back
->spin_lock(inode)
// check (I_NEW|I_FREEING|I_WILL_FREE) flags,
// passed and set I_FREEING
iput() ->spin_unlock(inode)
->spin_lock(inode) ->evict()
// dec i_count to 0
->iput_final()
->spin_unlock()
->evict()
Now, we have two threads simultaneously evicting
the same inode, which may trigger the BUG(inode->i_state & I_CLEAR)
statement both within clear_inode() and iput().
To fix the bug, recheck the inode->i_count after holding i_lock.
Because in the most scenarios, the first check is valid, and
the overhead of spin_lock() can be reduced.
If there is any misunderstanding, please let me know, thanks.
[1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@google.com/
[2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable()
return false when I reproduced the bug.
Reported-by: syzbot+67ba3c42bcbb4665d3ad@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=67ba3c42bcbb4665d3ad
CC: stable@vger.kernel.org
Fixes: 63997e98a3be ("split invalidate_inodes()")
Signed-off-by: Julian Sun <sunjunchao2870@gmail.com>
Link: https://lore.kernel.org/r/20240823130730.658881-1-sunjunchao2870@gmail.com
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-08-23 13:07:30 +00:00
|
|
|
if (atomic_read(&inode->i_count)) {
|
|
|
|
spin_unlock(&inode->i_lock);
|
|
|
|
continue;
|
|
|
|
}
|
2011-03-22 11:23:36 +00:00
|
|
|
if (inode->i_state & (I_NEW | I_FREEING | I_WILL_FREE)) {
|
|
|
|
spin_unlock(&inode->i_lock);
|
2005-04-16 22:20:36 +00:00
|
|
|
continue;
|
2011-03-22 11:23:36 +00:00
|
|
|
}
|
2010-10-26 00:49:35 +00:00
|
|
|
|
|
|
|
inode->i_state |= I_FREEING;
|
2011-03-22 11:23:38 +00:00
|
|
|
inode_lru_list_del(inode);
|
2011-03-22 11:23:36 +00:00
|
|
|
spin_unlock(&inode->i_lock);
|
2011-03-22 11:23:38 +00:00
|
|
|
list_add(&inode->i_lru, &dispose);
|
2015-03-04 21:52:52 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* We can have a ton of inodes to evict at unmount time given
|
|
|
|
* enough memory, check to see if we need to go to sleep for a
|
|
|
|
* bit so we don't livelock.
|
|
|
|
*/
|
|
|
|
if (need_resched()) {
|
|
|
|
spin_unlock(&sb->s_inode_list_lock);
|
|
|
|
cond_resched();
|
|
|
|
dispose_list(&dispose);
|
|
|
|
goto again;
|
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
2015-03-04 17:37:22 +00:00
|
|
|
spin_unlock(&sb->s_inode_list_lock);
|
2010-10-26 00:49:35 +00:00
|
|
|
|
|
|
|
dispose_list(&dispose);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
2017-08-19 01:08:25 +00:00
|
|
|
EXPORT_SYMBOL_GPL(evict_inodes);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
/**
|
2010-10-24 17:40:33 +00:00
|
|
|
* invalidate_inodes - attempt to free all inodes on a superblock
|
|
|
|
* @sb: superblock to operate on
|
2005-04-16 22:20:36 +00:00
|
|
|
*
|
2023-08-11 10:08:28 +00:00
|
|
|
* Attempts to free all inodes (including dirty inodes) for a given superblock.
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
2023-08-11 10:08:28 +00:00
|
|
|
void invalidate_inodes(struct super_block *sb)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2010-10-24 17:40:33 +00:00
|
|
|
struct inode *inode, *next;
|
|
|
|
LIST_HEAD(dispose);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2019-12-06 16:54:23 +00:00
|
|
|
again:
|
2015-03-04 17:37:22 +00:00
|
|
|
spin_lock(&sb->s_inode_list_lock);
|
2010-10-24 17:40:33 +00:00
|
|
|
list_for_each_entry_safe(inode, next, &sb->s_inodes, i_sb_list) {
|
2011-03-22 11:23:36 +00:00
|
|
|
spin_lock(&inode->i_lock);
|
|
|
|
if (inode->i_state & (I_NEW | I_FREEING | I_WILL_FREE)) {
|
|
|
|
spin_unlock(&inode->i_lock);
|
2009-03-11 20:17:36 +00:00
|
|
|
continue;
|
2011-03-22 11:23:36 +00:00
|
|
|
}
|
2010-10-23 17:07:20 +00:00
|
|
|
if (atomic_read(&inode->i_count)) {
|
2011-03-22 11:23:36 +00:00
|
|
|
spin_unlock(&inode->i_lock);
|
2005-04-16 22:20:36 +00:00
|
|
|
continue;
|
|
|
|
}
|
2010-10-23 17:07:20 +00:00
|
|
|
|
|
|
|
inode->i_state |= I_FREEING;
|
2011-03-22 11:23:38 +00:00
|
|
|
inode_lru_list_del(inode);
|
2011-03-22 11:23:36 +00:00
|
|
|
spin_unlock(&inode->i_lock);
|
2011-03-22 11:23:38 +00:00
|
|
|
list_add(&inode->i_lru, &dispose);
|
2019-12-06 16:54:23 +00:00
|
|
|
if (need_resched()) {
|
|
|
|
spin_unlock(&sb->s_inode_list_lock);
|
|
|
|
cond_resched();
|
|
|
|
dispose_list(&dispose);
|
|
|
|
goto again;
|
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
2015-03-04 17:37:22 +00:00
|
|
|
spin_unlock(&sb->s_inode_list_lock);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2010-10-24 17:40:33 +00:00
|
|
|
dispose_list(&dispose);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2013-08-28 00:17:58 +00:00
|
|
|
* Isolate the inode from the LRU in preparation for freeing it.
|
2005-04-16 22:20:36 +00:00
|
|
|
*
|
2010-10-23 10:55:17 +00:00
|
|
|
* If the inode has the I_REFERENCED flag set, then it means that it has been
|
|
|
|
* used recently - the flag is set in iput_final(). When we encounter such an
|
|
|
|
* inode, clear the flag and move it to the back of the LRU so it gets another
|
|
|
|
* pass through the LRU before it gets reclaimed. This is necessary because of
|
|
|
|
* the fact we are doing lazy LRU updates to minimise lock contention so the
|
|
|
|
* LRU does not have strict ordering. Hence we don't want to reclaim inodes
|
|
|
|
* with this flag set because they are the inodes that are out of order.
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
2015-02-12 22:59:35 +00:00
|
|
|
static enum lru_status inode_lru_isolate(struct list_head *item,
|
2024-11-04 17:52:57 +00:00
|
|
|
struct list_lru_one *lru, void *arg)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2013-08-28 00:17:58 +00:00
|
|
|
struct list_head *freeable = arg;
|
|
|
|
struct inode *inode = container_of(item, struct inode, i_lru);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2013-08-28 00:17:58 +00:00
|
|
|
/*
|
vfs: keep inodes with page cache off the inode shrinker LRU
Historically (pre-2.5), the inode shrinker used to reclaim only empty
inodes and skip over those that still contained page cache. This caused
problems on highmem hosts: struct inode could put fill lowmem zones
before the cache was getting reclaimed in the highmem zones.
To address this, the inode shrinker started to strip page cache to
facilitate reclaiming lowmem. However, this comes with its own set of
problems: the shrinkers may drop actively used page cache just because
the inodes are not currently open or dirty - think working with a large
git tree. It further doesn't respect cgroup memory protection settings
and can cause priority inversions between containers.
Nowadays, the page cache also holds non-resident info for evicted cache
pages in order to detect refaults. We've come to rely heavily on this
data inside reclaim for protecting the cache workingset and driving swap
behavior. We also use it to quantify and report workload health through
psi. The latter in turn is used for fleet health monitoring, as well as
driving automated memory sizing of workloads and containers, proactive
reclaim and memory offloading schemes.
The consequences of dropping page cache prematurely is that we're seeing
subtle and not-so-subtle failures in all of the above-mentioned
scenarios, with the workload generally entering unexpected thrashing
states while losing the ability to reliably detect it.
To fix this on non-highmem systems at least, going back to rotating
inodes on the LRU isn't feasible. We've tried (commit a76cf1a474d7
("mm: don't reclaim inodes with many attached pages")) and failed
(commit 69056ee6a8a3 ("Revert "mm: don't reclaim inodes with many
attached pages"")).
The issue is mostly that shrinker pools attract pressure based on their
size, and when objects get skipped the shrinkers remember this as
deferred reclaim work. This accumulates excessive pressure on the
remaining inodes, and we can quickly eat into heavily used ones, or
dirty ones that require IO to reclaim, when there potentially is plenty
of cold, clean cache around still.
Instead, this patch keeps populated inodes off the inode LRU in the
first place - just like an open file or dirty state would. An otherwise
clean and unused inode then gets queued when the last cache entry
disappears. This solves the problem without reintroducing the reclaim
issues, and generally is a bit more scalable than having to wade through
potentially hundreds of thousands of busy inodes.
Locking is a bit tricky because the locks protecting the inode state
(i_lock) and the inode LRU (lru_list.lock) don't nest inside the
irq-safe page cache lock (i_pages.xa_lock). Page cache deletions are
serialized through i_lock, taken before the i_pages lock, to make sure
depopulated inodes are queued reliably. Additions may race with
deletions, but we'll check again in the shrinker. If additions race
with the shrinker itself, we're protected by the i_lock: if find_inode()
or iput() win, the shrinker will bail on the elevated i_count or
I_REFERENCED; if the shrinker wins and goes ahead with the inode, it
will set I_FREEING and inhibit further igets(), which will cause the
other side to create a new instance of the inode instead.
Link: https://lkml.kernel.org/r/20210614211904.14420-4-hannes@cmpxchg.org
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: Roman Gushchin <guro@fb.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: Dave Chinner <david@fromorbit.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-11-09 02:31:24 +00:00
|
|
|
* We are inverting the lru lock/inode->i_lock here, so use a
|
|
|
|
* trylock. If we fail to get the lock, just skip it.
|
2013-08-28 00:17:58 +00:00
|
|
|
*/
|
|
|
|
if (!spin_trylock(&inode->i_lock))
|
|
|
|
return LRU_SKIP;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2013-08-28 00:17:58 +00:00
|
|
|
/*
|
vfs: keep inodes with page cache off the inode shrinker LRU
Historically (pre-2.5), the inode shrinker used to reclaim only empty
inodes and skip over those that still contained page cache. This caused
problems on highmem hosts: struct inode could put fill lowmem zones
before the cache was getting reclaimed in the highmem zones.
To address this, the inode shrinker started to strip page cache to
facilitate reclaiming lowmem. However, this comes with its own set of
problems: the shrinkers may drop actively used page cache just because
the inodes are not currently open or dirty - think working with a large
git tree. It further doesn't respect cgroup memory protection settings
and can cause priority inversions between containers.
Nowadays, the page cache also holds non-resident info for evicted cache
pages in order to detect refaults. We've come to rely heavily on this
data inside reclaim for protecting the cache workingset and driving swap
behavior. We also use it to quantify and report workload health through
psi. The latter in turn is used for fleet health monitoring, as well as
driving automated memory sizing of workloads and containers, proactive
reclaim and memory offloading schemes.
The consequences of dropping page cache prematurely is that we're seeing
subtle and not-so-subtle failures in all of the above-mentioned
scenarios, with the workload generally entering unexpected thrashing
states while losing the ability to reliably detect it.
To fix this on non-highmem systems at least, going back to rotating
inodes on the LRU isn't feasible. We've tried (commit a76cf1a474d7
("mm: don't reclaim inodes with many attached pages")) and failed
(commit 69056ee6a8a3 ("Revert "mm: don't reclaim inodes with many
attached pages"")).
The issue is mostly that shrinker pools attract pressure based on their
size, and when objects get skipped the shrinkers remember this as
deferred reclaim work. This accumulates excessive pressure on the
remaining inodes, and we can quickly eat into heavily used ones, or
dirty ones that require IO to reclaim, when there potentially is plenty
of cold, clean cache around still.
Instead, this patch keeps populated inodes off the inode LRU in the
first place - just like an open file or dirty state would. An otherwise
clean and unused inode then gets queued when the last cache entry
disappears. This solves the problem without reintroducing the reclaim
issues, and generally is a bit more scalable than having to wade through
potentially hundreds of thousands of busy inodes.
Locking is a bit tricky because the locks protecting the inode state
(i_lock) and the inode LRU (lru_list.lock) don't nest inside the
irq-safe page cache lock (i_pages.xa_lock). Page cache deletions are
serialized through i_lock, taken before the i_pages lock, to make sure
depopulated inodes are queued reliably. Additions may race with
deletions, but we'll check again in the shrinker. If additions race
with the shrinker itself, we're protected by the i_lock: if find_inode()
or iput() win, the shrinker will bail on the elevated i_count or
I_REFERENCED; if the shrinker wins and goes ahead with the inode, it
will set I_FREEING and inhibit further igets(), which will cause the
other side to create a new instance of the inode instead.
Link: https://lkml.kernel.org/r/20210614211904.14420-4-hannes@cmpxchg.org
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: Roman Gushchin <guro@fb.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: Dave Chinner <david@fromorbit.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-11-09 02:31:24 +00:00
|
|
|
* Inodes can get referenced, redirtied, or repopulated while
|
|
|
|
* they're already on the LRU, and this can make them
|
|
|
|
* unreclaimable for a while. Remove them lazily here; iput,
|
|
|
|
* sync, or the last page cache deletion will requeue them.
|
2013-08-28 00:17:58 +00:00
|
|
|
*/
|
|
|
|
if (atomic_read(&inode->i_count) ||
|
vfs: keep inodes with page cache off the inode shrinker LRU
Historically (pre-2.5), the inode shrinker used to reclaim only empty
inodes and skip over those that still contained page cache. This caused
problems on highmem hosts: struct inode could put fill lowmem zones
before the cache was getting reclaimed in the highmem zones.
To address this, the inode shrinker started to strip page cache to
facilitate reclaiming lowmem. However, this comes with its own set of
problems: the shrinkers may drop actively used page cache just because
the inodes are not currently open or dirty - think working with a large
git tree. It further doesn't respect cgroup memory protection settings
and can cause priority inversions between containers.
Nowadays, the page cache also holds non-resident info for evicted cache
pages in order to detect refaults. We've come to rely heavily on this
data inside reclaim for protecting the cache workingset and driving swap
behavior. We also use it to quantify and report workload health through
psi. The latter in turn is used for fleet health monitoring, as well as
driving automated memory sizing of workloads and containers, proactive
reclaim and memory offloading schemes.
The consequences of dropping page cache prematurely is that we're seeing
subtle and not-so-subtle failures in all of the above-mentioned
scenarios, with the workload generally entering unexpected thrashing
states while losing the ability to reliably detect it.
To fix this on non-highmem systems at least, going back to rotating
inodes on the LRU isn't feasible. We've tried (commit a76cf1a474d7
("mm: don't reclaim inodes with many attached pages")) and failed
(commit 69056ee6a8a3 ("Revert "mm: don't reclaim inodes with many
attached pages"")).
The issue is mostly that shrinker pools attract pressure based on their
size, and when objects get skipped the shrinkers remember this as
deferred reclaim work. This accumulates excessive pressure on the
remaining inodes, and we can quickly eat into heavily used ones, or
dirty ones that require IO to reclaim, when there potentially is plenty
of cold, clean cache around still.
Instead, this patch keeps populated inodes off the inode LRU in the
first place - just like an open file or dirty state would. An otherwise
clean and unused inode then gets queued when the last cache entry
disappears. This solves the problem without reintroducing the reclaim
issues, and generally is a bit more scalable than having to wade through
potentially hundreds of thousands of busy inodes.
Locking is a bit tricky because the locks protecting the inode state
(i_lock) and the inode LRU (lru_list.lock) don't nest inside the
irq-safe page cache lock (i_pages.xa_lock). Page cache deletions are
serialized through i_lock, taken before the i_pages lock, to make sure
depopulated inodes are queued reliably. Additions may race with
deletions, but we'll check again in the shrinker. If additions race
with the shrinker itself, we're protected by the i_lock: if find_inode()
or iput() win, the shrinker will bail on the elevated i_count or
I_REFERENCED; if the shrinker wins and goes ahead with the inode, it
will set I_FREEING and inhibit further igets(), which will cause the
other side to create a new instance of the inode instead.
Link: https://lkml.kernel.org/r/20210614211904.14420-4-hannes@cmpxchg.org
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: Roman Gushchin <guro@fb.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: Dave Chinner <david@fromorbit.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-11-09 02:31:24 +00:00
|
|
|
(inode->i_state & ~I_REFERENCED) ||
|
|
|
|
!mapping_shrinkable(&inode->i_data)) {
|
2015-02-12 22:59:35 +00:00
|
|
|
list_lru_isolate(lru, &inode->i_lru);
|
2013-08-28 00:17:58 +00:00
|
|
|
spin_unlock(&inode->i_lock);
|
|
|
|
this_cpu_dec(nr_unused);
|
|
|
|
return LRU_REMOVED;
|
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
|
vfs: keep inodes with page cache off the inode shrinker LRU
Historically (pre-2.5), the inode shrinker used to reclaim only empty
inodes and skip over those that still contained page cache. This caused
problems on highmem hosts: struct inode could put fill lowmem zones
before the cache was getting reclaimed in the highmem zones.
To address this, the inode shrinker started to strip page cache to
facilitate reclaiming lowmem. However, this comes with its own set of
problems: the shrinkers may drop actively used page cache just because
the inodes are not currently open or dirty - think working with a large
git tree. It further doesn't respect cgroup memory protection settings
and can cause priority inversions between containers.
Nowadays, the page cache also holds non-resident info for evicted cache
pages in order to detect refaults. We've come to rely heavily on this
data inside reclaim for protecting the cache workingset and driving swap
behavior. We also use it to quantify and report workload health through
psi. The latter in turn is used for fleet health monitoring, as well as
driving automated memory sizing of workloads and containers, proactive
reclaim and memory offloading schemes.
The consequences of dropping page cache prematurely is that we're seeing
subtle and not-so-subtle failures in all of the above-mentioned
scenarios, with the workload generally entering unexpected thrashing
states while losing the ability to reliably detect it.
To fix this on non-highmem systems at least, going back to rotating
inodes on the LRU isn't feasible. We've tried (commit a76cf1a474d7
("mm: don't reclaim inodes with many attached pages")) and failed
(commit 69056ee6a8a3 ("Revert "mm: don't reclaim inodes with many
attached pages"")).
The issue is mostly that shrinker pools attract pressure based on their
size, and when objects get skipped the shrinkers remember this as
deferred reclaim work. This accumulates excessive pressure on the
remaining inodes, and we can quickly eat into heavily used ones, or
dirty ones that require IO to reclaim, when there potentially is plenty
of cold, clean cache around still.
Instead, this patch keeps populated inodes off the inode LRU in the
first place - just like an open file or dirty state would. An otherwise
clean and unused inode then gets queued when the last cache entry
disappears. This solves the problem without reintroducing the reclaim
issues, and generally is a bit more scalable than having to wade through
potentially hundreds of thousands of busy inodes.
Locking is a bit tricky because the locks protecting the inode state
(i_lock) and the inode LRU (lru_list.lock) don't nest inside the
irq-safe page cache lock (i_pages.xa_lock). Page cache deletions are
serialized through i_lock, taken before the i_pages lock, to make sure
depopulated inodes are queued reliably. Additions may race with
deletions, but we'll check again in the shrinker. If additions race
with the shrinker itself, we're protected by the i_lock: if find_inode()
or iput() win, the shrinker will bail on the elevated i_count or
I_REFERENCED; if the shrinker wins and goes ahead with the inode, it
will set I_FREEING and inhibit further igets(), which will cause the
other side to create a new instance of the inode instead.
Link: https://lkml.kernel.org/r/20210614211904.14420-4-hannes@cmpxchg.org
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: Roman Gushchin <guro@fb.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: Dave Chinner <david@fromorbit.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-11-09 02:31:24 +00:00
|
|
|
/* Recently referenced inodes get one more pass */
|
2019-02-12 23:35:51 +00:00
|
|
|
if (inode->i_state & I_REFERENCED) {
|
2013-08-28 00:17:58 +00:00
|
|
|
inode->i_state &= ~I_REFERENCED;
|
|
|
|
spin_unlock(&inode->i_lock);
|
|
|
|
return LRU_ROTATE;
|
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
|
vfs: keep inodes with page cache off the inode shrinker LRU
Historically (pre-2.5), the inode shrinker used to reclaim only empty
inodes and skip over those that still contained page cache. This caused
problems on highmem hosts: struct inode could put fill lowmem zones
before the cache was getting reclaimed in the highmem zones.
To address this, the inode shrinker started to strip page cache to
facilitate reclaiming lowmem. However, this comes with its own set of
problems: the shrinkers may drop actively used page cache just because
the inodes are not currently open or dirty - think working with a large
git tree. It further doesn't respect cgroup memory protection settings
and can cause priority inversions between containers.
Nowadays, the page cache also holds non-resident info for evicted cache
pages in order to detect refaults. We've come to rely heavily on this
data inside reclaim for protecting the cache workingset and driving swap
behavior. We also use it to quantify and report workload health through
psi. The latter in turn is used for fleet health monitoring, as well as
driving automated memory sizing of workloads and containers, proactive
reclaim and memory offloading schemes.
The consequences of dropping page cache prematurely is that we're seeing
subtle and not-so-subtle failures in all of the above-mentioned
scenarios, with the workload generally entering unexpected thrashing
states while losing the ability to reliably detect it.
To fix this on non-highmem systems at least, going back to rotating
inodes on the LRU isn't feasible. We've tried (commit a76cf1a474d7
("mm: don't reclaim inodes with many attached pages")) and failed
(commit 69056ee6a8a3 ("Revert "mm: don't reclaim inodes with many
attached pages"")).
The issue is mostly that shrinker pools attract pressure based on their
size, and when objects get skipped the shrinkers remember this as
deferred reclaim work. This accumulates excessive pressure on the
remaining inodes, and we can quickly eat into heavily used ones, or
dirty ones that require IO to reclaim, when there potentially is plenty
of cold, clean cache around still.
Instead, this patch keeps populated inodes off the inode LRU in the
first place - just like an open file or dirty state would. An otherwise
clean and unused inode then gets queued when the last cache entry
disappears. This solves the problem without reintroducing the reclaim
issues, and generally is a bit more scalable than having to wade through
potentially hundreds of thousands of busy inodes.
Locking is a bit tricky because the locks protecting the inode state
(i_lock) and the inode LRU (lru_list.lock) don't nest inside the
irq-safe page cache lock (i_pages.xa_lock). Page cache deletions are
serialized through i_lock, taken before the i_pages lock, to make sure
depopulated inodes are queued reliably. Additions may race with
deletions, but we'll check again in the shrinker. If additions race
with the shrinker itself, we're protected by the i_lock: if find_inode()
or iput() win, the shrinker will bail on the elevated i_count or
I_REFERENCED; if the shrinker wins and goes ahead with the inode, it
will set I_FREEING and inhibit further igets(), which will cause the
other side to create a new instance of the inode instead.
Link: https://lkml.kernel.org/r/20210614211904.14420-4-hannes@cmpxchg.org
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: Roman Gushchin <guro@fb.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: Dave Chinner <david@fromorbit.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-11-09 02:31:24 +00:00
|
|
|
/*
|
|
|
|
* On highmem systems, mapping_shrinkable() permits dropping
|
|
|
|
* page cache in order to free up struct inodes: lowmem might
|
|
|
|
* be under pressure before the cache inside the highmem zone.
|
|
|
|
*/
|
2021-09-02 21:53:24 +00:00
|
|
|
if (inode_has_buffers(inode) || !mapping_empty(&inode->i_data)) {
|
vfs: Don't evict inode under the inode lru traversing context
The inode reclaiming process(See function prune_icache_sb) collects all
reclaimable inodes and mark them with I_FREEING flag at first, at that
time, other processes will be stuck if they try getting these inodes
(See function find_inode_fast), then the reclaiming process destroy the
inodes by function dispose_list(). Some filesystems(eg. ext4 with
ea_inode feature, ubifs with xattr) may do inode lookup in the inode
evicting callback function, if the inode lookup is operated under the
inode lru traversing context, deadlock problems may happen.
Case 1: In function ext4_evict_inode(), the ea inode lookup could happen
if ea_inode feature is enabled, the lookup process will be stuck
under the evicting context like this:
1. File A has inode i_reg and an ea inode i_ea
2. getfattr(A, xattr_buf) // i_ea is added into lru // lru->i_ea
3. Then, following three processes running like this:
PA PB
echo 2 > /proc/sys/vm/drop_caches
shrink_slab
prune_dcache_sb
// i_reg is added into lru, lru->i_ea->i_reg
prune_icache_sb
list_lru_walk_one
inode_lru_isolate
i_ea->i_state |= I_FREEING // set inode state
inode_lru_isolate
__iget(i_reg)
spin_unlock(&i_reg->i_lock)
spin_unlock(lru_lock)
rm file A
i_reg->nlink = 0
iput(i_reg) // i_reg->nlink is 0, do evict
ext4_evict_inode
ext4_xattr_delete_inode
ext4_xattr_inode_dec_ref_all
ext4_xattr_inode_iget
ext4_iget(i_ea->i_ino)
iget_locked
find_inode_fast
__wait_on_freeing_inode(i_ea) ----→ AA deadlock
dispose_list // cannot be executed by prune_icache_sb
wake_up_bit(&i_ea->i_state)
Case 2: In deleted inode writing function ubifs_jnl_write_inode(), file
deleting process holds BASEHD's wbuf->io_mutex while getting the
xattr inode, which could race with inode reclaiming process(The
reclaiming process could try locking BASEHD's wbuf->io_mutex in
inode evicting function), then an ABBA deadlock problem would
happen as following:
1. File A has inode ia and a xattr(with inode ixa), regular file B has
inode ib and a xattr.
2. getfattr(A, xattr_buf) // ixa is added into lru // lru->ixa
3. Then, following three processes running like this:
PA PB PC
echo 2 > /proc/sys/vm/drop_caches
shrink_slab
prune_dcache_sb
// ib and ia are added into lru, lru->ixa->ib->ia
prune_icache_sb
list_lru_walk_one
inode_lru_isolate
ixa->i_state |= I_FREEING // set inode state
inode_lru_isolate
__iget(ib)
spin_unlock(&ib->i_lock)
spin_unlock(lru_lock)
rm file B
ib->nlink = 0
rm file A
iput(ia)
ubifs_evict_inode(ia)
ubifs_jnl_delete_inode(ia)
ubifs_jnl_write_inode(ia)
make_reservation(BASEHD) // Lock wbuf->io_mutex
ubifs_iget(ixa->i_ino)
iget_locked
find_inode_fast
__wait_on_freeing_inode(ixa)
| iput(ib) // ib->nlink is 0, do evict
| ubifs_evict_inode
| ubifs_jnl_delete_inode(ib)
↓ ubifs_jnl_write_inode
ABBA deadlock ←-----make_reservation(BASEHD)
dispose_list // cannot be executed by prune_icache_sb
wake_up_bit(&ixa->i_state)
Fix the possible deadlock by using new inode state flag I_LRU_ISOLATING
to pin the inode in memory while inode_lru_isolate() reclaims its pages
instead of using ordinary inode reference. This way inode deletion
cannot be triggered from inode_lru_isolate() thus avoiding the deadlock.
evict() is made to wait for I_LRU_ISOLATING to be cleared before
proceeding with inode cleanup.
Link: https://lore.kernel.org/all/37c29c42-7685-d1f0-067d-63582ffac405@huaweicloud.com/
Link: https://bugzilla.kernel.org/show_bug.cgi?id=219022
Fixes: e50e5129f384 ("ext4: xattr-in-inode support")
Fixes: 7959cf3a7506 ("ubifs: journal: Handle xattrs like files")
Cc: stable@vger.kernel.org
Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
Link: https://lore.kernel.org/r/20240809031628.1069873-1-chengzhihao@huaweicloud.com
Reviewed-by: Jan Kara <jack@suse.cz>
Suggested-by: Jan Kara <jack@suse.cz>
Suggested-by: Mateusz Guzik <mjguzik@gmail.com>
Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-08-09 03:16:28 +00:00
|
|
|
inode_pin_lru_isolating(inode);
|
2013-08-28 00:17:58 +00:00
|
|
|
spin_unlock(&inode->i_lock);
|
2024-11-04 17:52:57 +00:00
|
|
|
spin_unlock(&lru->lock);
|
2013-08-28 00:17:58 +00:00
|
|
|
if (remove_inode_buffers(inode)) {
|
|
|
|
unsigned long reap;
|
|
|
|
reap = invalidate_mapping_pages(&inode->i_data, 0, -1);
|
|
|
|
if (current_is_kswapd())
|
|
|
|
__count_vm_events(KSWAPD_INODESTEAL, reap);
|
|
|
|
else
|
|
|
|
__count_vm_events(PGINODESTEAL, reap);
|
2023-04-13 10:40:34 +00:00
|
|
|
mm_account_reclaimed_pages(reap);
|
2011-03-22 11:23:38 +00:00
|
|
|
}
|
vfs: Don't evict inode under the inode lru traversing context
The inode reclaiming process(See function prune_icache_sb) collects all
reclaimable inodes and mark them with I_FREEING flag at first, at that
time, other processes will be stuck if they try getting these inodes
(See function find_inode_fast), then the reclaiming process destroy the
inodes by function dispose_list(). Some filesystems(eg. ext4 with
ea_inode feature, ubifs with xattr) may do inode lookup in the inode
evicting callback function, if the inode lookup is operated under the
inode lru traversing context, deadlock problems may happen.
Case 1: In function ext4_evict_inode(), the ea inode lookup could happen
if ea_inode feature is enabled, the lookup process will be stuck
under the evicting context like this:
1. File A has inode i_reg and an ea inode i_ea
2. getfattr(A, xattr_buf) // i_ea is added into lru // lru->i_ea
3. Then, following three processes running like this:
PA PB
echo 2 > /proc/sys/vm/drop_caches
shrink_slab
prune_dcache_sb
// i_reg is added into lru, lru->i_ea->i_reg
prune_icache_sb
list_lru_walk_one
inode_lru_isolate
i_ea->i_state |= I_FREEING // set inode state
inode_lru_isolate
__iget(i_reg)
spin_unlock(&i_reg->i_lock)
spin_unlock(lru_lock)
rm file A
i_reg->nlink = 0
iput(i_reg) // i_reg->nlink is 0, do evict
ext4_evict_inode
ext4_xattr_delete_inode
ext4_xattr_inode_dec_ref_all
ext4_xattr_inode_iget
ext4_iget(i_ea->i_ino)
iget_locked
find_inode_fast
__wait_on_freeing_inode(i_ea) ----→ AA deadlock
dispose_list // cannot be executed by prune_icache_sb
wake_up_bit(&i_ea->i_state)
Case 2: In deleted inode writing function ubifs_jnl_write_inode(), file
deleting process holds BASEHD's wbuf->io_mutex while getting the
xattr inode, which could race with inode reclaiming process(The
reclaiming process could try locking BASEHD's wbuf->io_mutex in
inode evicting function), then an ABBA deadlock problem would
happen as following:
1. File A has inode ia and a xattr(with inode ixa), regular file B has
inode ib and a xattr.
2. getfattr(A, xattr_buf) // ixa is added into lru // lru->ixa
3. Then, following three processes running like this:
PA PB PC
echo 2 > /proc/sys/vm/drop_caches
shrink_slab
prune_dcache_sb
// ib and ia are added into lru, lru->ixa->ib->ia
prune_icache_sb
list_lru_walk_one
inode_lru_isolate
ixa->i_state |= I_FREEING // set inode state
inode_lru_isolate
__iget(ib)
spin_unlock(&ib->i_lock)
spin_unlock(lru_lock)
rm file B
ib->nlink = 0
rm file A
iput(ia)
ubifs_evict_inode(ia)
ubifs_jnl_delete_inode(ia)
ubifs_jnl_write_inode(ia)
make_reservation(BASEHD) // Lock wbuf->io_mutex
ubifs_iget(ixa->i_ino)
iget_locked
find_inode_fast
__wait_on_freeing_inode(ixa)
| iput(ib) // ib->nlink is 0, do evict
| ubifs_evict_inode
| ubifs_jnl_delete_inode(ib)
↓ ubifs_jnl_write_inode
ABBA deadlock ←-----make_reservation(BASEHD)
dispose_list // cannot be executed by prune_icache_sb
wake_up_bit(&ixa->i_state)
Fix the possible deadlock by using new inode state flag I_LRU_ISOLATING
to pin the inode in memory while inode_lru_isolate() reclaims its pages
instead of using ordinary inode reference. This way inode deletion
cannot be triggered from inode_lru_isolate() thus avoiding the deadlock.
evict() is made to wait for I_LRU_ISOLATING to be cleared before
proceeding with inode cleanup.
Link: https://lore.kernel.org/all/37c29c42-7685-d1f0-067d-63582ffac405@huaweicloud.com/
Link: https://bugzilla.kernel.org/show_bug.cgi?id=219022
Fixes: e50e5129f384 ("ext4: xattr-in-inode support")
Fixes: 7959cf3a7506 ("ubifs: journal: Handle xattrs like files")
Cc: stable@vger.kernel.org
Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
Link: https://lore.kernel.org/r/20240809031628.1069873-1-chengzhihao@huaweicloud.com
Reviewed-by: Jan Kara <jack@suse.cz>
Suggested-by: Jan Kara <jack@suse.cz>
Suggested-by: Mateusz Guzik <mjguzik@gmail.com>
Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-08-09 03:16:28 +00:00
|
|
|
inode_unpin_lru_isolating(inode);
|
2013-08-28 00:17:58 +00:00
|
|
|
return LRU_RETRY;
|
|
|
|
}
|
2011-03-22 11:23:38 +00:00
|
|
|
|
2013-08-28 00:17:58 +00:00
|
|
|
WARN_ON(inode->i_state & I_NEW);
|
|
|
|
inode->i_state |= I_FREEING;
|
2015-02-12 22:59:35 +00:00
|
|
|
list_lru_isolate_move(lru, &inode->i_lru, freeable);
|
2013-08-28 00:17:58 +00:00
|
|
|
spin_unlock(&inode->i_lock);
|
2010-10-23 10:55:17 +00:00
|
|
|
|
2013-08-28 00:17:58 +00:00
|
|
|
this_cpu_dec(nr_unused);
|
|
|
|
return LRU_REMOVED;
|
|
|
|
}
|
2010-10-21 00:49:30 +00:00
|
|
|
|
2013-08-28 00:17:58 +00:00
|
|
|
/*
|
|
|
|
* Walk the superblock inode LRU for freeable inodes and attempt to free them.
|
|
|
|
* This is called from the superblock shrinker function with a number of inodes
|
|
|
|
* to trim from the LRU. Inodes to be freed are moved to a temporary list and
|
|
|
|
* then are freed outside inode_lock by dispose_list().
|
|
|
|
*/
|
list_lru: introduce list_lru_shrink_{count,walk}
Kmem accounting of memcg is unusable now, because it lacks slab shrinker
support. That means when we hit the limit we will get ENOMEM w/o any
chance to recover. What we should do then is to call shrink_slab, which
would reclaim old inode/dentry caches from this cgroup. This is what
this patch set is intended to do.
Basically, it does two things. First, it introduces the notion of
per-memcg slab shrinker. A shrinker that wants to reclaim objects per
cgroup should mark itself as SHRINKER_MEMCG_AWARE. Then it will be
passed the memory cgroup to scan from in shrink_control->memcg. For
such shrinkers shrink_slab iterates over the whole cgroup subtree under
the target cgroup and calls the shrinker for each kmem-active memory
cgroup.
Secondly, this patch set makes the list_lru structure per-memcg. It's
done transparently to list_lru users - everything they have to do is to
tell list_lru_init that they want memcg-aware list_lru. Then the
list_lru will automatically distribute objects among per-memcg lists
basing on which cgroup the object is accounted to. This way to make FS
shrinkers (icache, dcache) memcg-aware we only need to make them use
memcg-aware list_lru, and this is what this patch set does.
As before, this patch set only enables per-memcg kmem reclaim when the
pressure goes from memory.limit, not from memory.kmem.limit. Handling
memory.kmem.limit is going to be tricky due to GFP_NOFS allocations, and
it is still unclear whether we will have this knob in the unified
hierarchy.
This patch (of 9):
NUMA aware slab shrinkers use the list_lru structure to distribute
objects coming from different NUMA nodes to different lists. Whenever
such a shrinker needs to count or scan objects from a particular node,
it issues commands like this:
count = list_lru_count_node(lru, sc->nid);
freed = list_lru_walk_node(lru, sc->nid, isolate_func,
isolate_arg, &sc->nr_to_scan);
where sc is an instance of the shrink_control structure passed to it
from vmscan.
To simplify this, let's add special list_lru functions to be used by
shrinkers, list_lru_shrink_count() and list_lru_shrink_walk(), which
consolidate the nid and nr_to_scan arguments in the shrink_control
structure.
This will also allow us to avoid patching shrinkers that use list_lru
when we make shrink_slab() per-memcg - all we will have to do is extend
the shrink_control structure to include the target memcg and make
list_lru_shrink_{count,walk} handle this appropriately.
Signed-off-by: Vladimir Davydov <vdavydov@parallels.com>
Suggested-by: Dave Chinner <david@fromorbit.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Michal Hocko <mhocko@suse.cz>
Cc: Greg Thelen <gthelen@google.com>
Cc: Glauber Costa <glommer@gmail.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Tejun Heo <tj@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-02-12 22:58:47 +00:00
|
|
|
long prune_icache_sb(struct super_block *sb, struct shrink_control *sc)
|
2013-08-28 00:17:58 +00:00
|
|
|
{
|
|
|
|
LIST_HEAD(freeable);
|
|
|
|
long freed;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
list_lru: introduce list_lru_shrink_{count,walk}
Kmem accounting of memcg is unusable now, because it lacks slab shrinker
support. That means when we hit the limit we will get ENOMEM w/o any
chance to recover. What we should do then is to call shrink_slab, which
would reclaim old inode/dentry caches from this cgroup. This is what
this patch set is intended to do.
Basically, it does two things. First, it introduces the notion of
per-memcg slab shrinker. A shrinker that wants to reclaim objects per
cgroup should mark itself as SHRINKER_MEMCG_AWARE. Then it will be
passed the memory cgroup to scan from in shrink_control->memcg. For
such shrinkers shrink_slab iterates over the whole cgroup subtree under
the target cgroup and calls the shrinker for each kmem-active memory
cgroup.
Secondly, this patch set makes the list_lru structure per-memcg. It's
done transparently to list_lru users - everything they have to do is to
tell list_lru_init that they want memcg-aware list_lru. Then the
list_lru will automatically distribute objects among per-memcg lists
basing on which cgroup the object is accounted to. This way to make FS
shrinkers (icache, dcache) memcg-aware we only need to make them use
memcg-aware list_lru, and this is what this patch set does.
As before, this patch set only enables per-memcg kmem reclaim when the
pressure goes from memory.limit, not from memory.kmem.limit. Handling
memory.kmem.limit is going to be tricky due to GFP_NOFS allocations, and
it is still unclear whether we will have this knob in the unified
hierarchy.
This patch (of 9):
NUMA aware slab shrinkers use the list_lru structure to distribute
objects coming from different NUMA nodes to different lists. Whenever
such a shrinker needs to count or scan objects from a particular node,
it issues commands like this:
count = list_lru_count_node(lru, sc->nid);
freed = list_lru_walk_node(lru, sc->nid, isolate_func,
isolate_arg, &sc->nr_to_scan);
where sc is an instance of the shrink_control structure passed to it
from vmscan.
To simplify this, let's add special list_lru functions to be used by
shrinkers, list_lru_shrink_count() and list_lru_shrink_walk(), which
consolidate the nid and nr_to_scan arguments in the shrink_control
structure.
This will also allow us to avoid patching shrinkers that use list_lru
when we make shrink_slab() per-memcg - all we will have to do is extend
the shrink_control structure to include the target memcg and make
list_lru_shrink_{count,walk} handle this appropriately.
Signed-off-by: Vladimir Davydov <vdavydov@parallels.com>
Suggested-by: Dave Chinner <david@fromorbit.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Michal Hocko <mhocko@suse.cz>
Cc: Greg Thelen <gthelen@google.com>
Cc: Glauber Costa <glommer@gmail.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Tejun Heo <tj@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-02-12 22:58:47 +00:00
|
|
|
freed = list_lru_shrink_walk(&sb->s_inode_lru, sc,
|
|
|
|
inode_lru_isolate, &freeable);
|
2005-04-16 22:20:36 +00:00
|
|
|
dispose_list(&freeable);
|
2013-08-28 00:17:57 +00:00
|
|
|
return freed;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
2024-07-24 08:50:33 +00:00
|
|
|
static void __wait_on_freeing_inode(struct inode *inode, bool is_inode_hash_locked);
|
2005-04-16 22:20:36 +00:00
|
|
|
/*
|
|
|
|
* Called with the inode lock held.
|
|
|
|
*/
|
2009-03-31 14:05:54 +00:00
|
|
|
static struct inode *find_inode(struct super_block *sb,
|
|
|
|
struct hlist_head *head,
|
|
|
|
int (*test)(struct inode *, void *),
|
2024-07-24 08:50:33 +00:00
|
|
|
void *data, bool is_inode_hash_locked)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2009-03-31 14:05:54 +00:00
|
|
|
struct inode *inode = NULL;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2024-07-24 08:50:33 +00:00
|
|
|
if (is_inode_hash_locked)
|
vfs: add rcu-based find_inode variants for iget ops
This avoids one inode hash lock acquire in the common case on inode
creation, in effect significantly reducing contention.
On the stock kernel said lock is typically taken twice:
1. once to check if the inode happens to already be present
2. once to add it to the hash
The back-to-back lock/unlock pattern is known to degrade performance
significantly, which is further exacerbated if the hash is heavily
populated (long chains to walk, extending hold time). Arguably hash
sizing and hashing algo need to be revisited, but that's beyond the
scope of this patch.
With the acquire from step 1 eliminated with RCU lookup throughput
increases significantly at the scale of 20 cores (benchmark results at
the bottom).
So happens the hash already supports RCU-based operation, but lookups on
inode insertions didn't take advantage of it.
This of course has its limits as the global lock is still a bottleneck.
There was a patchset posted which introduced fine-grained locking[1] but
it appears staled. Apart from that doubt was expressed whether a
handrolled hash implementation is appropriate to begin with, suggesting
replacement with rhashtables. Nobody committed to carrying [1] across
the finish line or implementing anything better, thus the bandaid below.
iget_locked consumers (notably ext4) get away without any changes
because inode comparison method is built-in.
iget5_locked consumers pass a custom callback. Since removal of locking
adds more problems (inode can be changing) it's not safe to assume all
filesystems happen to cope. Thus iget5_locked_rcu gets added, requiring
manual conversion of interested filesystems.
In order to reduce code duplication find_inode and find_inode_fast grow
an argument indicating whether inode hash lock is held, which is passed
down in case sleeping is necessary. They always rcu_read_lock, which is
redundant but harmless. Doing it conditionally reduces readability for
no real gain that I can see. RCU-alike restrictions were already put on
callbacks due to the hash spinlock being held.
Benchmarking:
There is a real cache-busting workload scanning millions of files in
parallel (it's a backup appliance), where the initial lookup is
guaranteed to fail resulting in the two lock acquires on stock kernel
(and one with the patch at hand).
Implemented below is a synthetic benchmark providing the same behavior.
[I shall note the workload is not running on Linux, instead it was
causing trouble elsewhere. Benchmark below was used while addressing
said problems and was found to adequately represent the real workload.]
Total real time fluctuates by 1-2s.
With 20 threads each walking a dedicated 1000 dirs * 1000 files
directory tree to stat(2) on a 32 core + 24GB RAM vm:
ext4 (needed mkfs.ext4 -N 24000000):
before: 3.77s user 890.90s system 1939% cpu 46.118 total
after: 3.24s user 397.73s system 1858% cpu 21.581 total (-53%)
That's 20 million files to visit, while the machine can only cache about
15 million at a time (obtained from ext4_inode_cache object count in
/proc/slabinfo). Since each terminal inode is only visited once per run
this amounts to 0% hit ratio for the dentry cache and the hash table
(there are however hits for the intermediate directories).
On repeated runs the kernel caches the last ~15 mln, meaning there is ~5
mln of uncached inodes which are going to be visited first, evicting the
previously cached state as it happens.
Lack of hits can be trivially verified with bpftrace, like so:
bpftrace -e 'kretprobe:find_inode_fast { @[kstack(), retval != 0] = count(); }'\
-c "/bin/sh walktrees /testfs 20"
Best ran more than once.
Expected results after "warmup":
[snip]
@[
__ext4_iget+275
ext4_lookup+224
__lookup_slow+130
walk_component+219
link_path_walk.part.0.constprop.0+614
path_lookupat+62
filename_lookup+204
vfs_statx+128
vfs_fstatat+131
__do_sys_newfstatat+38
do_syscall_64+87
entry_SYSCALL_64_after_hwframe+118
, 1]: 20000
@[
__ext4_iget+275
ext4_lookup+224
__lookup_slow+130
walk_component+219
path_lookupat+106
filename_lookup+204
vfs_statx+128
vfs_fstatat+131
__do_sys_newfstatat+38
do_syscall_64+87
entry_SYSCALL_64_after_hwframe+118
, 1]: 20000000
That is 20 million calls for the initial lookup and 20 million after
allocating a new inode, all of them failing to return a value != 0
(i.e., they are returning NULL -- no match found).
Of course aborting the benchmark in the middle and starting it again (or
messing with the state in other ways) is going to alter these results.
Benchmark can be found here: https://people.freebsd.org/~mjg/fstree.tgz
[1] https://lore.kernel.org/all/20231206060629.2827226-1-david@fromorbit.com/
Signed-off-by: Mateusz Guzik <mjguzik@gmail.com>
Link: https://lore.kernel.org/r/20240611173824.535995-2-mjguzik@gmail.com
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-06-11 17:38:22 +00:00
|
|
|
lockdep_assert_held(&inode_hash_lock);
|
|
|
|
else
|
|
|
|
lockdep_assert_not_held(&inode_hash_lock);
|
|
|
|
|
|
|
|
rcu_read_lock();
|
2005-04-16 22:20:36 +00:00
|
|
|
repeat:
|
vfs: add rcu-based find_inode variants for iget ops
This avoids one inode hash lock acquire in the common case on inode
creation, in effect significantly reducing contention.
On the stock kernel said lock is typically taken twice:
1. once to check if the inode happens to already be present
2. once to add it to the hash
The back-to-back lock/unlock pattern is known to degrade performance
significantly, which is further exacerbated if the hash is heavily
populated (long chains to walk, extending hold time). Arguably hash
sizing and hashing algo need to be revisited, but that's beyond the
scope of this patch.
With the acquire from step 1 eliminated with RCU lookup throughput
increases significantly at the scale of 20 cores (benchmark results at
the bottom).
So happens the hash already supports RCU-based operation, but lookups on
inode insertions didn't take advantage of it.
This of course has its limits as the global lock is still a bottleneck.
There was a patchset posted which introduced fine-grained locking[1] but
it appears staled. Apart from that doubt was expressed whether a
handrolled hash implementation is appropriate to begin with, suggesting
replacement with rhashtables. Nobody committed to carrying [1] across
the finish line or implementing anything better, thus the bandaid below.
iget_locked consumers (notably ext4) get away without any changes
because inode comparison method is built-in.
iget5_locked consumers pass a custom callback. Since removal of locking
adds more problems (inode can be changing) it's not safe to assume all
filesystems happen to cope. Thus iget5_locked_rcu gets added, requiring
manual conversion of interested filesystems.
In order to reduce code duplication find_inode and find_inode_fast grow
an argument indicating whether inode hash lock is held, which is passed
down in case sleeping is necessary. They always rcu_read_lock, which is
redundant but harmless. Doing it conditionally reduces readability for
no real gain that I can see. RCU-alike restrictions were already put on
callbacks due to the hash spinlock being held.
Benchmarking:
There is a real cache-busting workload scanning millions of files in
parallel (it's a backup appliance), where the initial lookup is
guaranteed to fail resulting in the two lock acquires on stock kernel
(and one with the patch at hand).
Implemented below is a synthetic benchmark providing the same behavior.
[I shall note the workload is not running on Linux, instead it was
causing trouble elsewhere. Benchmark below was used while addressing
said problems and was found to adequately represent the real workload.]
Total real time fluctuates by 1-2s.
With 20 threads each walking a dedicated 1000 dirs * 1000 files
directory tree to stat(2) on a 32 core + 24GB RAM vm:
ext4 (needed mkfs.ext4 -N 24000000):
before: 3.77s user 890.90s system 1939% cpu 46.118 total
after: 3.24s user 397.73s system 1858% cpu 21.581 total (-53%)
That's 20 million files to visit, while the machine can only cache about
15 million at a time (obtained from ext4_inode_cache object count in
/proc/slabinfo). Since each terminal inode is only visited once per run
this amounts to 0% hit ratio for the dentry cache and the hash table
(there are however hits for the intermediate directories).
On repeated runs the kernel caches the last ~15 mln, meaning there is ~5
mln of uncached inodes which are going to be visited first, evicting the
previously cached state as it happens.
Lack of hits can be trivially verified with bpftrace, like so:
bpftrace -e 'kretprobe:find_inode_fast { @[kstack(), retval != 0] = count(); }'\
-c "/bin/sh walktrees /testfs 20"
Best ran more than once.
Expected results after "warmup":
[snip]
@[
__ext4_iget+275
ext4_lookup+224
__lookup_slow+130
walk_component+219
link_path_walk.part.0.constprop.0+614
path_lookupat+62
filename_lookup+204
vfs_statx+128
vfs_fstatat+131
__do_sys_newfstatat+38
do_syscall_64+87
entry_SYSCALL_64_after_hwframe+118
, 1]: 20000
@[
__ext4_iget+275
ext4_lookup+224
__lookup_slow+130
walk_component+219
path_lookupat+106
filename_lookup+204
vfs_statx+128
vfs_fstatat+131
__do_sys_newfstatat+38
do_syscall_64+87
entry_SYSCALL_64_after_hwframe+118
, 1]: 20000000
That is 20 million calls for the initial lookup and 20 million after
allocating a new inode, all of them failing to return a value != 0
(i.e., they are returning NULL -- no match found).
Of course aborting the benchmark in the middle and starting it again (or
messing with the state in other ways) is going to alter these results.
Benchmark can be found here: https://people.freebsd.org/~mjg/fstree.tgz
[1] https://lore.kernel.org/all/20231206060629.2827226-1-david@fromorbit.com/
Signed-off-by: Mateusz Guzik <mjguzik@gmail.com>
Link: https://lore.kernel.org/r/20240611173824.535995-2-mjguzik@gmail.com
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-06-11 17:38:22 +00:00
|
|
|
hlist_for_each_entry_rcu(inode, head, i_hash) {
|
2013-11-06 14:54:52 +00:00
|
|
|
if (inode->i_sb != sb)
|
2005-04-16 22:20:36 +00:00
|
|
|
continue;
|
2013-11-06 14:54:52 +00:00
|
|
|
if (!test(inode, data))
|
2005-04-16 22:20:36 +00:00
|
|
|
continue;
|
2013-11-06 14:54:52 +00:00
|
|
|
spin_lock(&inode->i_lock);
|
2010-06-02 21:38:30 +00:00
|
|
|
if (inode->i_state & (I_FREEING|I_WILL_FREE)) {
|
2024-07-24 08:50:33 +00:00
|
|
|
__wait_on_freeing_inode(inode, is_inode_hash_locked);
|
2005-04-16 22:20:36 +00:00
|
|
|
goto repeat;
|
|
|
|
}
|
2018-06-28 19:53:17 +00:00
|
|
|
if (unlikely(inode->i_state & I_CREATING)) {
|
|
|
|
spin_unlock(&inode->i_lock);
|
vfs: add rcu-based find_inode variants for iget ops
This avoids one inode hash lock acquire in the common case on inode
creation, in effect significantly reducing contention.
On the stock kernel said lock is typically taken twice:
1. once to check if the inode happens to already be present
2. once to add it to the hash
The back-to-back lock/unlock pattern is known to degrade performance
significantly, which is further exacerbated if the hash is heavily
populated (long chains to walk, extending hold time). Arguably hash
sizing and hashing algo need to be revisited, but that's beyond the
scope of this patch.
With the acquire from step 1 eliminated with RCU lookup throughput
increases significantly at the scale of 20 cores (benchmark results at
the bottom).
So happens the hash already supports RCU-based operation, but lookups on
inode insertions didn't take advantage of it.
This of course has its limits as the global lock is still a bottleneck.
There was a patchset posted which introduced fine-grained locking[1] but
it appears staled. Apart from that doubt was expressed whether a
handrolled hash implementation is appropriate to begin with, suggesting
replacement with rhashtables. Nobody committed to carrying [1] across
the finish line or implementing anything better, thus the bandaid below.
iget_locked consumers (notably ext4) get away without any changes
because inode comparison method is built-in.
iget5_locked consumers pass a custom callback. Since removal of locking
adds more problems (inode can be changing) it's not safe to assume all
filesystems happen to cope. Thus iget5_locked_rcu gets added, requiring
manual conversion of interested filesystems.
In order to reduce code duplication find_inode and find_inode_fast grow
an argument indicating whether inode hash lock is held, which is passed
down in case sleeping is necessary. They always rcu_read_lock, which is
redundant but harmless. Doing it conditionally reduces readability for
no real gain that I can see. RCU-alike restrictions were already put on
callbacks due to the hash spinlock being held.
Benchmarking:
There is a real cache-busting workload scanning millions of files in
parallel (it's a backup appliance), where the initial lookup is
guaranteed to fail resulting in the two lock acquires on stock kernel
(and one with the patch at hand).
Implemented below is a synthetic benchmark providing the same behavior.
[I shall note the workload is not running on Linux, instead it was
causing trouble elsewhere. Benchmark below was used while addressing
said problems and was found to adequately represent the real workload.]
Total real time fluctuates by 1-2s.
With 20 threads each walking a dedicated 1000 dirs * 1000 files
directory tree to stat(2) on a 32 core + 24GB RAM vm:
ext4 (needed mkfs.ext4 -N 24000000):
before: 3.77s user 890.90s system 1939% cpu 46.118 total
after: 3.24s user 397.73s system 1858% cpu 21.581 total (-53%)
That's 20 million files to visit, while the machine can only cache about
15 million at a time (obtained from ext4_inode_cache object count in
/proc/slabinfo). Since each terminal inode is only visited once per run
this amounts to 0% hit ratio for the dentry cache and the hash table
(there are however hits for the intermediate directories).
On repeated runs the kernel caches the last ~15 mln, meaning there is ~5
mln of uncached inodes which are going to be visited first, evicting the
previously cached state as it happens.
Lack of hits can be trivially verified with bpftrace, like so:
bpftrace -e 'kretprobe:find_inode_fast { @[kstack(), retval != 0] = count(); }'\
-c "/bin/sh walktrees /testfs 20"
Best ran more than once.
Expected results after "warmup":
[snip]
@[
__ext4_iget+275
ext4_lookup+224
__lookup_slow+130
walk_component+219
link_path_walk.part.0.constprop.0+614
path_lookupat+62
filename_lookup+204
vfs_statx+128
vfs_fstatat+131
__do_sys_newfstatat+38
do_syscall_64+87
entry_SYSCALL_64_after_hwframe+118
, 1]: 20000
@[
__ext4_iget+275
ext4_lookup+224
__lookup_slow+130
walk_component+219
path_lookupat+106
filename_lookup+204
vfs_statx+128
vfs_fstatat+131
__do_sys_newfstatat+38
do_syscall_64+87
entry_SYSCALL_64_after_hwframe+118
, 1]: 20000000
That is 20 million calls for the initial lookup and 20 million after
allocating a new inode, all of them failing to return a value != 0
(i.e., they are returning NULL -- no match found).
Of course aborting the benchmark in the middle and starting it again (or
messing with the state in other ways) is going to alter these results.
Benchmark can be found here: https://people.freebsd.org/~mjg/fstree.tgz
[1] https://lore.kernel.org/all/20231206060629.2827226-1-david@fromorbit.com/
Signed-off-by: Mateusz Guzik <mjguzik@gmail.com>
Link: https://lore.kernel.org/r/20240611173824.535995-2-mjguzik@gmail.com
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-06-11 17:38:22 +00:00
|
|
|
rcu_read_unlock();
|
2018-06-28 19:53:17 +00:00
|
|
|
return ERR_PTR(-ESTALE);
|
|
|
|
}
|
2010-10-23 11:09:06 +00:00
|
|
|
__iget(inode);
|
2011-03-22 11:23:36 +00:00
|
|
|
spin_unlock(&inode->i_lock);
|
vfs: add rcu-based find_inode variants for iget ops
This avoids one inode hash lock acquire in the common case on inode
creation, in effect significantly reducing contention.
On the stock kernel said lock is typically taken twice:
1. once to check if the inode happens to already be present
2. once to add it to the hash
The back-to-back lock/unlock pattern is known to degrade performance
significantly, which is further exacerbated if the hash is heavily
populated (long chains to walk, extending hold time). Arguably hash
sizing and hashing algo need to be revisited, but that's beyond the
scope of this patch.
With the acquire from step 1 eliminated with RCU lookup throughput
increases significantly at the scale of 20 cores (benchmark results at
the bottom).
So happens the hash already supports RCU-based operation, but lookups on
inode insertions didn't take advantage of it.
This of course has its limits as the global lock is still a bottleneck.
There was a patchset posted which introduced fine-grained locking[1] but
it appears staled. Apart from that doubt was expressed whether a
handrolled hash implementation is appropriate to begin with, suggesting
replacement with rhashtables. Nobody committed to carrying [1] across
the finish line or implementing anything better, thus the bandaid below.
iget_locked consumers (notably ext4) get away without any changes
because inode comparison method is built-in.
iget5_locked consumers pass a custom callback. Since removal of locking
adds more problems (inode can be changing) it's not safe to assume all
filesystems happen to cope. Thus iget5_locked_rcu gets added, requiring
manual conversion of interested filesystems.
In order to reduce code duplication find_inode and find_inode_fast grow
an argument indicating whether inode hash lock is held, which is passed
down in case sleeping is necessary. They always rcu_read_lock, which is
redundant but harmless. Doing it conditionally reduces readability for
no real gain that I can see. RCU-alike restrictions were already put on
callbacks due to the hash spinlock being held.
Benchmarking:
There is a real cache-busting workload scanning millions of files in
parallel (it's a backup appliance), where the initial lookup is
guaranteed to fail resulting in the two lock acquires on stock kernel
(and one with the patch at hand).
Implemented below is a synthetic benchmark providing the same behavior.
[I shall note the workload is not running on Linux, instead it was
causing trouble elsewhere. Benchmark below was used while addressing
said problems and was found to adequately represent the real workload.]
Total real time fluctuates by 1-2s.
With 20 threads each walking a dedicated 1000 dirs * 1000 files
directory tree to stat(2) on a 32 core + 24GB RAM vm:
ext4 (needed mkfs.ext4 -N 24000000):
before: 3.77s user 890.90s system 1939% cpu 46.118 total
after: 3.24s user 397.73s system 1858% cpu 21.581 total (-53%)
That's 20 million files to visit, while the machine can only cache about
15 million at a time (obtained from ext4_inode_cache object count in
/proc/slabinfo). Since each terminal inode is only visited once per run
this amounts to 0% hit ratio for the dentry cache and the hash table
(there are however hits for the intermediate directories).
On repeated runs the kernel caches the last ~15 mln, meaning there is ~5
mln of uncached inodes which are going to be visited first, evicting the
previously cached state as it happens.
Lack of hits can be trivially verified with bpftrace, like so:
bpftrace -e 'kretprobe:find_inode_fast { @[kstack(), retval != 0] = count(); }'\
-c "/bin/sh walktrees /testfs 20"
Best ran more than once.
Expected results after "warmup":
[snip]
@[
__ext4_iget+275
ext4_lookup+224
__lookup_slow+130
walk_component+219
link_path_walk.part.0.constprop.0+614
path_lookupat+62
filename_lookup+204
vfs_statx+128
vfs_fstatat+131
__do_sys_newfstatat+38
do_syscall_64+87
entry_SYSCALL_64_after_hwframe+118
, 1]: 20000
@[
__ext4_iget+275
ext4_lookup+224
__lookup_slow+130
walk_component+219
path_lookupat+106
filename_lookup+204
vfs_statx+128
vfs_fstatat+131
__do_sys_newfstatat+38
do_syscall_64+87
entry_SYSCALL_64_after_hwframe+118
, 1]: 20000000
That is 20 million calls for the initial lookup and 20 million after
allocating a new inode, all of them failing to return a value != 0
(i.e., they are returning NULL -- no match found).
Of course aborting the benchmark in the middle and starting it again (or
messing with the state in other ways) is going to alter these results.
Benchmark can be found here: https://people.freebsd.org/~mjg/fstree.tgz
[1] https://lore.kernel.org/all/20231206060629.2827226-1-david@fromorbit.com/
Signed-off-by: Mateusz Guzik <mjguzik@gmail.com>
Link: https://lore.kernel.org/r/20240611173824.535995-2-mjguzik@gmail.com
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-06-11 17:38:22 +00:00
|
|
|
rcu_read_unlock();
|
2010-10-23 11:09:06 +00:00
|
|
|
return inode;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
vfs: add rcu-based find_inode variants for iget ops
This avoids one inode hash lock acquire in the common case on inode
creation, in effect significantly reducing contention.
On the stock kernel said lock is typically taken twice:
1. once to check if the inode happens to already be present
2. once to add it to the hash
The back-to-back lock/unlock pattern is known to degrade performance
significantly, which is further exacerbated if the hash is heavily
populated (long chains to walk, extending hold time). Arguably hash
sizing and hashing algo need to be revisited, but that's beyond the
scope of this patch.
With the acquire from step 1 eliminated with RCU lookup throughput
increases significantly at the scale of 20 cores (benchmark results at
the bottom).
So happens the hash already supports RCU-based operation, but lookups on
inode insertions didn't take advantage of it.
This of course has its limits as the global lock is still a bottleneck.
There was a patchset posted which introduced fine-grained locking[1] but
it appears staled. Apart from that doubt was expressed whether a
handrolled hash implementation is appropriate to begin with, suggesting
replacement with rhashtables. Nobody committed to carrying [1] across
the finish line or implementing anything better, thus the bandaid below.
iget_locked consumers (notably ext4) get away without any changes
because inode comparison method is built-in.
iget5_locked consumers pass a custom callback. Since removal of locking
adds more problems (inode can be changing) it's not safe to assume all
filesystems happen to cope. Thus iget5_locked_rcu gets added, requiring
manual conversion of interested filesystems.
In order to reduce code duplication find_inode and find_inode_fast grow
an argument indicating whether inode hash lock is held, which is passed
down in case sleeping is necessary. They always rcu_read_lock, which is
redundant but harmless. Doing it conditionally reduces readability for
no real gain that I can see. RCU-alike restrictions were already put on
callbacks due to the hash spinlock being held.
Benchmarking:
There is a real cache-busting workload scanning millions of files in
parallel (it's a backup appliance), where the initial lookup is
guaranteed to fail resulting in the two lock acquires on stock kernel
(and one with the patch at hand).
Implemented below is a synthetic benchmark providing the same behavior.
[I shall note the workload is not running on Linux, instead it was
causing trouble elsewhere. Benchmark below was used while addressing
said problems and was found to adequately represent the real workload.]
Total real time fluctuates by 1-2s.
With 20 threads each walking a dedicated 1000 dirs * 1000 files
directory tree to stat(2) on a 32 core + 24GB RAM vm:
ext4 (needed mkfs.ext4 -N 24000000):
before: 3.77s user 890.90s system 1939% cpu 46.118 total
after: 3.24s user 397.73s system 1858% cpu 21.581 total (-53%)
That's 20 million files to visit, while the machine can only cache about
15 million at a time (obtained from ext4_inode_cache object count in
/proc/slabinfo). Since each terminal inode is only visited once per run
this amounts to 0% hit ratio for the dentry cache and the hash table
(there are however hits for the intermediate directories).
On repeated runs the kernel caches the last ~15 mln, meaning there is ~5
mln of uncached inodes which are going to be visited first, evicting the
previously cached state as it happens.
Lack of hits can be trivially verified with bpftrace, like so:
bpftrace -e 'kretprobe:find_inode_fast { @[kstack(), retval != 0] = count(); }'\
-c "/bin/sh walktrees /testfs 20"
Best ran more than once.
Expected results after "warmup":
[snip]
@[
__ext4_iget+275
ext4_lookup+224
__lookup_slow+130
walk_component+219
link_path_walk.part.0.constprop.0+614
path_lookupat+62
filename_lookup+204
vfs_statx+128
vfs_fstatat+131
__do_sys_newfstatat+38
do_syscall_64+87
entry_SYSCALL_64_after_hwframe+118
, 1]: 20000
@[
__ext4_iget+275
ext4_lookup+224
__lookup_slow+130
walk_component+219
path_lookupat+106
filename_lookup+204
vfs_statx+128
vfs_fstatat+131
__do_sys_newfstatat+38
do_syscall_64+87
entry_SYSCALL_64_after_hwframe+118
, 1]: 20000000
That is 20 million calls for the initial lookup and 20 million after
allocating a new inode, all of them failing to return a value != 0
(i.e., they are returning NULL -- no match found).
Of course aborting the benchmark in the middle and starting it again (or
messing with the state in other ways) is going to alter these results.
Benchmark can be found here: https://people.freebsd.org/~mjg/fstree.tgz
[1] https://lore.kernel.org/all/20231206060629.2827226-1-david@fromorbit.com/
Signed-off-by: Mateusz Guzik <mjguzik@gmail.com>
Link: https://lore.kernel.org/r/20240611173824.535995-2-mjguzik@gmail.com
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-06-11 17:38:22 +00:00
|
|
|
rcu_read_unlock();
|
2010-10-23 11:09:06 +00:00
|
|
|
return NULL;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* find_inode_fast is the fast path version of find_inode, see the comment at
|
|
|
|
* iget_locked for details.
|
|
|
|
*/
|
2009-03-31 14:05:54 +00:00
|
|
|
static struct inode *find_inode_fast(struct super_block *sb,
|
vfs: add rcu-based find_inode variants for iget ops
This avoids one inode hash lock acquire in the common case on inode
creation, in effect significantly reducing contention.
On the stock kernel said lock is typically taken twice:
1. once to check if the inode happens to already be present
2. once to add it to the hash
The back-to-back lock/unlock pattern is known to degrade performance
significantly, which is further exacerbated if the hash is heavily
populated (long chains to walk, extending hold time). Arguably hash
sizing and hashing algo need to be revisited, but that's beyond the
scope of this patch.
With the acquire from step 1 eliminated with RCU lookup throughput
increases significantly at the scale of 20 cores (benchmark results at
the bottom).
So happens the hash already supports RCU-based operation, but lookups on
inode insertions didn't take advantage of it.
This of course has its limits as the global lock is still a bottleneck.
There was a patchset posted which introduced fine-grained locking[1] but
it appears staled. Apart from that doubt was expressed whether a
handrolled hash implementation is appropriate to begin with, suggesting
replacement with rhashtables. Nobody committed to carrying [1] across
the finish line or implementing anything better, thus the bandaid below.
iget_locked consumers (notably ext4) get away without any changes
because inode comparison method is built-in.
iget5_locked consumers pass a custom callback. Since removal of locking
adds more problems (inode can be changing) it's not safe to assume all
filesystems happen to cope. Thus iget5_locked_rcu gets added, requiring
manual conversion of interested filesystems.
In order to reduce code duplication find_inode and find_inode_fast grow
an argument indicating whether inode hash lock is held, which is passed
down in case sleeping is necessary. They always rcu_read_lock, which is
redundant but harmless. Doing it conditionally reduces readability for
no real gain that I can see. RCU-alike restrictions were already put on
callbacks due to the hash spinlock being held.
Benchmarking:
There is a real cache-busting workload scanning millions of files in
parallel (it's a backup appliance), where the initial lookup is
guaranteed to fail resulting in the two lock acquires on stock kernel
(and one with the patch at hand).
Implemented below is a synthetic benchmark providing the same behavior.
[I shall note the workload is not running on Linux, instead it was
causing trouble elsewhere. Benchmark below was used while addressing
said problems and was found to adequately represent the real workload.]
Total real time fluctuates by 1-2s.
With 20 threads each walking a dedicated 1000 dirs * 1000 files
directory tree to stat(2) on a 32 core + 24GB RAM vm:
ext4 (needed mkfs.ext4 -N 24000000):
before: 3.77s user 890.90s system 1939% cpu 46.118 total
after: 3.24s user 397.73s system 1858% cpu 21.581 total (-53%)
That's 20 million files to visit, while the machine can only cache about
15 million at a time (obtained from ext4_inode_cache object count in
/proc/slabinfo). Since each terminal inode is only visited once per run
this amounts to 0% hit ratio for the dentry cache and the hash table
(there are however hits for the intermediate directories).
On repeated runs the kernel caches the last ~15 mln, meaning there is ~5
mln of uncached inodes which are going to be visited first, evicting the
previously cached state as it happens.
Lack of hits can be trivially verified with bpftrace, like so:
bpftrace -e 'kretprobe:find_inode_fast { @[kstack(), retval != 0] = count(); }'\
-c "/bin/sh walktrees /testfs 20"
Best ran more than once.
Expected results after "warmup":
[snip]
@[
__ext4_iget+275
ext4_lookup+224
__lookup_slow+130
walk_component+219
link_path_walk.part.0.constprop.0+614
path_lookupat+62
filename_lookup+204
vfs_statx+128
vfs_fstatat+131
__do_sys_newfstatat+38
do_syscall_64+87
entry_SYSCALL_64_after_hwframe+118
, 1]: 20000
@[
__ext4_iget+275
ext4_lookup+224
__lookup_slow+130
walk_component+219
path_lookupat+106
filename_lookup+204
vfs_statx+128
vfs_fstatat+131
__do_sys_newfstatat+38
do_syscall_64+87
entry_SYSCALL_64_after_hwframe+118
, 1]: 20000000
That is 20 million calls for the initial lookup and 20 million after
allocating a new inode, all of them failing to return a value != 0
(i.e., they are returning NULL -- no match found).
Of course aborting the benchmark in the middle and starting it again (or
messing with the state in other ways) is going to alter these results.
Benchmark can be found here: https://people.freebsd.org/~mjg/fstree.tgz
[1] https://lore.kernel.org/all/20231206060629.2827226-1-david@fromorbit.com/
Signed-off-by: Mateusz Guzik <mjguzik@gmail.com>
Link: https://lore.kernel.org/r/20240611173824.535995-2-mjguzik@gmail.com
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-06-11 17:38:22 +00:00
|
|
|
struct hlist_head *head, unsigned long ino,
|
2024-07-24 08:50:33 +00:00
|
|
|
bool is_inode_hash_locked)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2009-03-31 14:05:54 +00:00
|
|
|
struct inode *inode = NULL;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2024-07-24 08:50:33 +00:00
|
|
|
if (is_inode_hash_locked)
|
vfs: add rcu-based find_inode variants for iget ops
This avoids one inode hash lock acquire in the common case on inode
creation, in effect significantly reducing contention.
On the stock kernel said lock is typically taken twice:
1. once to check if the inode happens to already be present
2. once to add it to the hash
The back-to-back lock/unlock pattern is known to degrade performance
significantly, which is further exacerbated if the hash is heavily
populated (long chains to walk, extending hold time). Arguably hash
sizing and hashing algo need to be revisited, but that's beyond the
scope of this patch.
With the acquire from step 1 eliminated with RCU lookup throughput
increases significantly at the scale of 20 cores (benchmark results at
the bottom).
So happens the hash already supports RCU-based operation, but lookups on
inode insertions didn't take advantage of it.
This of course has its limits as the global lock is still a bottleneck.
There was a patchset posted which introduced fine-grained locking[1] but
it appears staled. Apart from that doubt was expressed whether a
handrolled hash implementation is appropriate to begin with, suggesting
replacement with rhashtables. Nobody committed to carrying [1] across
the finish line or implementing anything better, thus the bandaid below.
iget_locked consumers (notably ext4) get away without any changes
because inode comparison method is built-in.
iget5_locked consumers pass a custom callback. Since removal of locking
adds more problems (inode can be changing) it's not safe to assume all
filesystems happen to cope. Thus iget5_locked_rcu gets added, requiring
manual conversion of interested filesystems.
In order to reduce code duplication find_inode and find_inode_fast grow
an argument indicating whether inode hash lock is held, which is passed
down in case sleeping is necessary. They always rcu_read_lock, which is
redundant but harmless. Doing it conditionally reduces readability for
no real gain that I can see. RCU-alike restrictions were already put on
callbacks due to the hash spinlock being held.
Benchmarking:
There is a real cache-busting workload scanning millions of files in
parallel (it's a backup appliance), where the initial lookup is
guaranteed to fail resulting in the two lock acquires on stock kernel
(and one with the patch at hand).
Implemented below is a synthetic benchmark providing the same behavior.
[I shall note the workload is not running on Linux, instead it was
causing trouble elsewhere. Benchmark below was used while addressing
said problems and was found to adequately represent the real workload.]
Total real time fluctuates by 1-2s.
With 20 threads each walking a dedicated 1000 dirs * 1000 files
directory tree to stat(2) on a 32 core + 24GB RAM vm:
ext4 (needed mkfs.ext4 -N 24000000):
before: 3.77s user 890.90s system 1939% cpu 46.118 total
after: 3.24s user 397.73s system 1858% cpu 21.581 total (-53%)
That's 20 million files to visit, while the machine can only cache about
15 million at a time (obtained from ext4_inode_cache object count in
/proc/slabinfo). Since each terminal inode is only visited once per run
this amounts to 0% hit ratio for the dentry cache and the hash table
(there are however hits for the intermediate directories).
On repeated runs the kernel caches the last ~15 mln, meaning there is ~5
mln of uncached inodes which are going to be visited first, evicting the
previously cached state as it happens.
Lack of hits can be trivially verified with bpftrace, like so:
bpftrace -e 'kretprobe:find_inode_fast { @[kstack(), retval != 0] = count(); }'\
-c "/bin/sh walktrees /testfs 20"
Best ran more than once.
Expected results after "warmup":
[snip]
@[
__ext4_iget+275
ext4_lookup+224
__lookup_slow+130
walk_component+219
link_path_walk.part.0.constprop.0+614
path_lookupat+62
filename_lookup+204
vfs_statx+128
vfs_fstatat+131
__do_sys_newfstatat+38
do_syscall_64+87
entry_SYSCALL_64_after_hwframe+118
, 1]: 20000
@[
__ext4_iget+275
ext4_lookup+224
__lookup_slow+130
walk_component+219
path_lookupat+106
filename_lookup+204
vfs_statx+128
vfs_fstatat+131
__do_sys_newfstatat+38
do_syscall_64+87
entry_SYSCALL_64_after_hwframe+118
, 1]: 20000000
That is 20 million calls for the initial lookup and 20 million after
allocating a new inode, all of them failing to return a value != 0
(i.e., they are returning NULL -- no match found).
Of course aborting the benchmark in the middle and starting it again (or
messing with the state in other ways) is going to alter these results.
Benchmark can be found here: https://people.freebsd.org/~mjg/fstree.tgz
[1] https://lore.kernel.org/all/20231206060629.2827226-1-david@fromorbit.com/
Signed-off-by: Mateusz Guzik <mjguzik@gmail.com>
Link: https://lore.kernel.org/r/20240611173824.535995-2-mjguzik@gmail.com
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-06-11 17:38:22 +00:00
|
|
|
lockdep_assert_held(&inode_hash_lock);
|
|
|
|
else
|
|
|
|
lockdep_assert_not_held(&inode_hash_lock);
|
|
|
|
|
|
|
|
rcu_read_lock();
|
2005-04-16 22:20:36 +00:00
|
|
|
repeat:
|
vfs: add rcu-based find_inode variants for iget ops
This avoids one inode hash lock acquire in the common case on inode
creation, in effect significantly reducing contention.
On the stock kernel said lock is typically taken twice:
1. once to check if the inode happens to already be present
2. once to add it to the hash
The back-to-back lock/unlock pattern is known to degrade performance
significantly, which is further exacerbated if the hash is heavily
populated (long chains to walk, extending hold time). Arguably hash
sizing and hashing algo need to be revisited, but that's beyond the
scope of this patch.
With the acquire from step 1 eliminated with RCU lookup throughput
increases significantly at the scale of 20 cores (benchmark results at
the bottom).
So happens the hash already supports RCU-based operation, but lookups on
inode insertions didn't take advantage of it.
This of course has its limits as the global lock is still a bottleneck.
There was a patchset posted which introduced fine-grained locking[1] but
it appears staled. Apart from that doubt was expressed whether a
handrolled hash implementation is appropriate to begin with, suggesting
replacement with rhashtables. Nobody committed to carrying [1] across
the finish line or implementing anything better, thus the bandaid below.
iget_locked consumers (notably ext4) get away without any changes
because inode comparison method is built-in.
iget5_locked consumers pass a custom callback. Since removal of locking
adds more problems (inode can be changing) it's not safe to assume all
filesystems happen to cope. Thus iget5_locked_rcu gets added, requiring
manual conversion of interested filesystems.
In order to reduce code duplication find_inode and find_inode_fast grow
an argument indicating whether inode hash lock is held, which is passed
down in case sleeping is necessary. They always rcu_read_lock, which is
redundant but harmless. Doing it conditionally reduces readability for
no real gain that I can see. RCU-alike restrictions were already put on
callbacks due to the hash spinlock being held.
Benchmarking:
There is a real cache-busting workload scanning millions of files in
parallel (it's a backup appliance), where the initial lookup is
guaranteed to fail resulting in the two lock acquires on stock kernel
(and one with the patch at hand).
Implemented below is a synthetic benchmark providing the same behavior.
[I shall note the workload is not running on Linux, instead it was
causing trouble elsewhere. Benchmark below was used while addressing
said problems and was found to adequately represent the real workload.]
Total real time fluctuates by 1-2s.
With 20 threads each walking a dedicated 1000 dirs * 1000 files
directory tree to stat(2) on a 32 core + 24GB RAM vm:
ext4 (needed mkfs.ext4 -N 24000000):
before: 3.77s user 890.90s system 1939% cpu 46.118 total
after: 3.24s user 397.73s system 1858% cpu 21.581 total (-53%)
That's 20 million files to visit, while the machine can only cache about
15 million at a time (obtained from ext4_inode_cache object count in
/proc/slabinfo). Since each terminal inode is only visited once per run
this amounts to 0% hit ratio for the dentry cache and the hash table
(there are however hits for the intermediate directories).
On repeated runs the kernel caches the last ~15 mln, meaning there is ~5
mln of uncached inodes which are going to be visited first, evicting the
previously cached state as it happens.
Lack of hits can be trivially verified with bpftrace, like so:
bpftrace -e 'kretprobe:find_inode_fast { @[kstack(), retval != 0] = count(); }'\
-c "/bin/sh walktrees /testfs 20"
Best ran more than once.
Expected results after "warmup":
[snip]
@[
__ext4_iget+275
ext4_lookup+224
__lookup_slow+130
walk_component+219
link_path_walk.part.0.constprop.0+614
path_lookupat+62
filename_lookup+204
vfs_statx+128
vfs_fstatat+131
__do_sys_newfstatat+38
do_syscall_64+87
entry_SYSCALL_64_after_hwframe+118
, 1]: 20000
@[
__ext4_iget+275
ext4_lookup+224
__lookup_slow+130
walk_component+219
path_lookupat+106
filename_lookup+204
vfs_statx+128
vfs_fstatat+131
__do_sys_newfstatat+38
do_syscall_64+87
entry_SYSCALL_64_after_hwframe+118
, 1]: 20000000
That is 20 million calls for the initial lookup and 20 million after
allocating a new inode, all of them failing to return a value != 0
(i.e., they are returning NULL -- no match found).
Of course aborting the benchmark in the middle and starting it again (or
messing with the state in other ways) is going to alter these results.
Benchmark can be found here: https://people.freebsd.org/~mjg/fstree.tgz
[1] https://lore.kernel.org/all/20231206060629.2827226-1-david@fromorbit.com/
Signed-off-by: Mateusz Guzik <mjguzik@gmail.com>
Link: https://lore.kernel.org/r/20240611173824.535995-2-mjguzik@gmail.com
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-06-11 17:38:22 +00:00
|
|
|
hlist_for_each_entry_rcu(inode, head, i_hash) {
|
2013-11-06 14:54:52 +00:00
|
|
|
if (inode->i_ino != ino)
|
2005-04-16 22:20:36 +00:00
|
|
|
continue;
|
2013-11-06 14:54:52 +00:00
|
|
|
if (inode->i_sb != sb)
|
2005-04-16 22:20:36 +00:00
|
|
|
continue;
|
2013-11-06 14:54:52 +00:00
|
|
|
spin_lock(&inode->i_lock);
|
2010-06-02 21:38:30 +00:00
|
|
|
if (inode->i_state & (I_FREEING|I_WILL_FREE)) {
|
2024-07-24 08:50:33 +00:00
|
|
|
__wait_on_freeing_inode(inode, is_inode_hash_locked);
|
2005-04-16 22:20:36 +00:00
|
|
|
goto repeat;
|
|
|
|
}
|
2018-06-28 19:53:17 +00:00
|
|
|
if (unlikely(inode->i_state & I_CREATING)) {
|
|
|
|
spin_unlock(&inode->i_lock);
|
vfs: add rcu-based find_inode variants for iget ops
This avoids one inode hash lock acquire in the common case on inode
creation, in effect significantly reducing contention.
On the stock kernel said lock is typically taken twice:
1. once to check if the inode happens to already be present
2. once to add it to the hash
The back-to-back lock/unlock pattern is known to degrade performance
significantly, which is further exacerbated if the hash is heavily
populated (long chains to walk, extending hold time). Arguably hash
sizing and hashing algo need to be revisited, but that's beyond the
scope of this patch.
With the acquire from step 1 eliminated with RCU lookup throughput
increases significantly at the scale of 20 cores (benchmark results at
the bottom).
So happens the hash already supports RCU-based operation, but lookups on
inode insertions didn't take advantage of it.
This of course has its limits as the global lock is still a bottleneck.
There was a patchset posted which introduced fine-grained locking[1] but
it appears staled. Apart from that doubt was expressed whether a
handrolled hash implementation is appropriate to begin with, suggesting
replacement with rhashtables. Nobody committed to carrying [1] across
the finish line or implementing anything better, thus the bandaid below.
iget_locked consumers (notably ext4) get away without any changes
because inode comparison method is built-in.
iget5_locked consumers pass a custom callback. Since removal of locking
adds more problems (inode can be changing) it's not safe to assume all
filesystems happen to cope. Thus iget5_locked_rcu gets added, requiring
manual conversion of interested filesystems.
In order to reduce code duplication find_inode and find_inode_fast grow
an argument indicating whether inode hash lock is held, which is passed
down in case sleeping is necessary. They always rcu_read_lock, which is
redundant but harmless. Doing it conditionally reduces readability for
no real gain that I can see. RCU-alike restrictions were already put on
callbacks due to the hash spinlock being held.
Benchmarking:
There is a real cache-busting workload scanning millions of files in
parallel (it's a backup appliance), where the initial lookup is
guaranteed to fail resulting in the two lock acquires on stock kernel
(and one with the patch at hand).
Implemented below is a synthetic benchmark providing the same behavior.
[I shall note the workload is not running on Linux, instead it was
causing trouble elsewhere. Benchmark below was used while addressing
said problems and was found to adequately represent the real workload.]
Total real time fluctuates by 1-2s.
With 20 threads each walking a dedicated 1000 dirs * 1000 files
directory tree to stat(2) on a 32 core + 24GB RAM vm:
ext4 (needed mkfs.ext4 -N 24000000):
before: 3.77s user 890.90s system 1939% cpu 46.118 total
after: 3.24s user 397.73s system 1858% cpu 21.581 total (-53%)
That's 20 million files to visit, while the machine can only cache about
15 million at a time (obtained from ext4_inode_cache object count in
/proc/slabinfo). Since each terminal inode is only visited once per run
this amounts to 0% hit ratio for the dentry cache and the hash table
(there are however hits for the intermediate directories).
On repeated runs the kernel caches the last ~15 mln, meaning there is ~5
mln of uncached inodes which are going to be visited first, evicting the
previously cached state as it happens.
Lack of hits can be trivially verified with bpftrace, like so:
bpftrace -e 'kretprobe:find_inode_fast { @[kstack(), retval != 0] = count(); }'\
-c "/bin/sh walktrees /testfs 20"
Best ran more than once.
Expected results after "warmup":
[snip]
@[
__ext4_iget+275
ext4_lookup+224
__lookup_slow+130
walk_component+219
link_path_walk.part.0.constprop.0+614
path_lookupat+62
filename_lookup+204
vfs_statx+128
vfs_fstatat+131
__do_sys_newfstatat+38
do_syscall_64+87
entry_SYSCALL_64_after_hwframe+118
, 1]: 20000
@[
__ext4_iget+275
ext4_lookup+224
__lookup_slow+130
walk_component+219
path_lookupat+106
filename_lookup+204
vfs_statx+128
vfs_fstatat+131
__do_sys_newfstatat+38
do_syscall_64+87
entry_SYSCALL_64_after_hwframe+118
, 1]: 20000000
That is 20 million calls for the initial lookup and 20 million after
allocating a new inode, all of them failing to return a value != 0
(i.e., they are returning NULL -- no match found).
Of course aborting the benchmark in the middle and starting it again (or
messing with the state in other ways) is going to alter these results.
Benchmark can be found here: https://people.freebsd.org/~mjg/fstree.tgz
[1] https://lore.kernel.org/all/20231206060629.2827226-1-david@fromorbit.com/
Signed-off-by: Mateusz Guzik <mjguzik@gmail.com>
Link: https://lore.kernel.org/r/20240611173824.535995-2-mjguzik@gmail.com
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-06-11 17:38:22 +00:00
|
|
|
rcu_read_unlock();
|
2018-06-28 19:53:17 +00:00
|
|
|
return ERR_PTR(-ESTALE);
|
|
|
|
}
|
2010-10-23 11:09:06 +00:00
|
|
|
__iget(inode);
|
2011-03-22 11:23:36 +00:00
|
|
|
spin_unlock(&inode->i_lock);
|
vfs: add rcu-based find_inode variants for iget ops
This avoids one inode hash lock acquire in the common case on inode
creation, in effect significantly reducing contention.
On the stock kernel said lock is typically taken twice:
1. once to check if the inode happens to already be present
2. once to add it to the hash
The back-to-back lock/unlock pattern is known to degrade performance
significantly, which is further exacerbated if the hash is heavily
populated (long chains to walk, extending hold time). Arguably hash
sizing and hashing algo need to be revisited, but that's beyond the
scope of this patch.
With the acquire from step 1 eliminated with RCU lookup throughput
increases significantly at the scale of 20 cores (benchmark results at
the bottom).
So happens the hash already supports RCU-based operation, but lookups on
inode insertions didn't take advantage of it.
This of course has its limits as the global lock is still a bottleneck.
There was a patchset posted which introduced fine-grained locking[1] but
it appears staled. Apart from that doubt was expressed whether a
handrolled hash implementation is appropriate to begin with, suggesting
replacement with rhashtables. Nobody committed to carrying [1] across
the finish line or implementing anything better, thus the bandaid below.
iget_locked consumers (notably ext4) get away without any changes
because inode comparison method is built-in.
iget5_locked consumers pass a custom callback. Since removal of locking
adds more problems (inode can be changing) it's not safe to assume all
filesystems happen to cope. Thus iget5_locked_rcu gets added, requiring
manual conversion of interested filesystems.
In order to reduce code duplication find_inode and find_inode_fast grow
an argument indicating whether inode hash lock is held, which is passed
down in case sleeping is necessary. They always rcu_read_lock, which is
redundant but harmless. Doing it conditionally reduces readability for
no real gain that I can see. RCU-alike restrictions were already put on
callbacks due to the hash spinlock being held.
Benchmarking:
There is a real cache-busting workload scanning millions of files in
parallel (it's a backup appliance), where the initial lookup is
guaranteed to fail resulting in the two lock acquires on stock kernel
(and one with the patch at hand).
Implemented below is a synthetic benchmark providing the same behavior.
[I shall note the workload is not running on Linux, instead it was
causing trouble elsewhere. Benchmark below was used while addressing
said problems and was found to adequately represent the real workload.]
Total real time fluctuates by 1-2s.
With 20 threads each walking a dedicated 1000 dirs * 1000 files
directory tree to stat(2) on a 32 core + 24GB RAM vm:
ext4 (needed mkfs.ext4 -N 24000000):
before: 3.77s user 890.90s system 1939% cpu 46.118 total
after: 3.24s user 397.73s system 1858% cpu 21.581 total (-53%)
That's 20 million files to visit, while the machine can only cache about
15 million at a time (obtained from ext4_inode_cache object count in
/proc/slabinfo). Since each terminal inode is only visited once per run
this amounts to 0% hit ratio for the dentry cache and the hash table
(there are however hits for the intermediate directories).
On repeated runs the kernel caches the last ~15 mln, meaning there is ~5
mln of uncached inodes which are going to be visited first, evicting the
previously cached state as it happens.
Lack of hits can be trivially verified with bpftrace, like so:
bpftrace -e 'kretprobe:find_inode_fast { @[kstack(), retval != 0] = count(); }'\
-c "/bin/sh walktrees /testfs 20"
Best ran more than once.
Expected results after "warmup":
[snip]
@[
__ext4_iget+275
ext4_lookup+224
__lookup_slow+130
walk_component+219
link_path_walk.part.0.constprop.0+614
path_lookupat+62
filename_lookup+204
vfs_statx+128
vfs_fstatat+131
__do_sys_newfstatat+38
do_syscall_64+87
entry_SYSCALL_64_after_hwframe+118
, 1]: 20000
@[
__ext4_iget+275
ext4_lookup+224
__lookup_slow+130
walk_component+219
path_lookupat+106
filename_lookup+204
vfs_statx+128
vfs_fstatat+131
__do_sys_newfstatat+38
do_syscall_64+87
entry_SYSCALL_64_after_hwframe+118
, 1]: 20000000
That is 20 million calls for the initial lookup and 20 million after
allocating a new inode, all of them failing to return a value != 0
(i.e., they are returning NULL -- no match found).
Of course aborting the benchmark in the middle and starting it again (or
messing with the state in other ways) is going to alter these results.
Benchmark can be found here: https://people.freebsd.org/~mjg/fstree.tgz
[1] https://lore.kernel.org/all/20231206060629.2827226-1-david@fromorbit.com/
Signed-off-by: Mateusz Guzik <mjguzik@gmail.com>
Link: https://lore.kernel.org/r/20240611173824.535995-2-mjguzik@gmail.com
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-06-11 17:38:22 +00:00
|
|
|
rcu_read_unlock();
|
2010-10-23 11:09:06 +00:00
|
|
|
return inode;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
vfs: add rcu-based find_inode variants for iget ops
This avoids one inode hash lock acquire in the common case on inode
creation, in effect significantly reducing contention.
On the stock kernel said lock is typically taken twice:
1. once to check if the inode happens to already be present
2. once to add it to the hash
The back-to-back lock/unlock pattern is known to degrade performance
significantly, which is further exacerbated if the hash is heavily
populated (long chains to walk, extending hold time). Arguably hash
sizing and hashing algo need to be revisited, but that's beyond the
scope of this patch.
With the acquire from step 1 eliminated with RCU lookup throughput
increases significantly at the scale of 20 cores (benchmark results at
the bottom).
So happens the hash already supports RCU-based operation, but lookups on
inode insertions didn't take advantage of it.
This of course has its limits as the global lock is still a bottleneck.
There was a patchset posted which introduced fine-grained locking[1] but
it appears staled. Apart from that doubt was expressed whether a
handrolled hash implementation is appropriate to begin with, suggesting
replacement with rhashtables. Nobody committed to carrying [1] across
the finish line or implementing anything better, thus the bandaid below.
iget_locked consumers (notably ext4) get away without any changes
because inode comparison method is built-in.
iget5_locked consumers pass a custom callback. Since removal of locking
adds more problems (inode can be changing) it's not safe to assume all
filesystems happen to cope. Thus iget5_locked_rcu gets added, requiring
manual conversion of interested filesystems.
In order to reduce code duplication find_inode and find_inode_fast grow
an argument indicating whether inode hash lock is held, which is passed
down in case sleeping is necessary. They always rcu_read_lock, which is
redundant but harmless. Doing it conditionally reduces readability for
no real gain that I can see. RCU-alike restrictions were already put on
callbacks due to the hash spinlock being held.
Benchmarking:
There is a real cache-busting workload scanning millions of files in
parallel (it's a backup appliance), where the initial lookup is
guaranteed to fail resulting in the two lock acquires on stock kernel
(and one with the patch at hand).
Implemented below is a synthetic benchmark providing the same behavior.
[I shall note the workload is not running on Linux, instead it was
causing trouble elsewhere. Benchmark below was used while addressing
said problems and was found to adequately represent the real workload.]
Total real time fluctuates by 1-2s.
With 20 threads each walking a dedicated 1000 dirs * 1000 files
directory tree to stat(2) on a 32 core + 24GB RAM vm:
ext4 (needed mkfs.ext4 -N 24000000):
before: 3.77s user 890.90s system 1939% cpu 46.118 total
after: 3.24s user 397.73s system 1858% cpu 21.581 total (-53%)
That's 20 million files to visit, while the machine can only cache about
15 million at a time (obtained from ext4_inode_cache object count in
/proc/slabinfo). Since each terminal inode is only visited once per run
this amounts to 0% hit ratio for the dentry cache and the hash table
(there are however hits for the intermediate directories).
On repeated runs the kernel caches the last ~15 mln, meaning there is ~5
mln of uncached inodes which are going to be visited first, evicting the
previously cached state as it happens.
Lack of hits can be trivially verified with bpftrace, like so:
bpftrace -e 'kretprobe:find_inode_fast { @[kstack(), retval != 0] = count(); }'\
-c "/bin/sh walktrees /testfs 20"
Best ran more than once.
Expected results after "warmup":
[snip]
@[
__ext4_iget+275
ext4_lookup+224
__lookup_slow+130
walk_component+219
link_path_walk.part.0.constprop.0+614
path_lookupat+62
filename_lookup+204
vfs_statx+128
vfs_fstatat+131
__do_sys_newfstatat+38
do_syscall_64+87
entry_SYSCALL_64_after_hwframe+118
, 1]: 20000
@[
__ext4_iget+275
ext4_lookup+224
__lookup_slow+130
walk_component+219
path_lookupat+106
filename_lookup+204
vfs_statx+128
vfs_fstatat+131
__do_sys_newfstatat+38
do_syscall_64+87
entry_SYSCALL_64_after_hwframe+118
, 1]: 20000000
That is 20 million calls for the initial lookup and 20 million after
allocating a new inode, all of them failing to return a value != 0
(i.e., they are returning NULL -- no match found).
Of course aborting the benchmark in the middle and starting it again (or
messing with the state in other ways) is going to alter these results.
Benchmark can be found here: https://people.freebsd.org/~mjg/fstree.tgz
[1] https://lore.kernel.org/all/20231206060629.2827226-1-david@fromorbit.com/
Signed-off-by: Mateusz Guzik <mjguzik@gmail.com>
Link: https://lore.kernel.org/r/20240611173824.535995-2-mjguzik@gmail.com
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-06-11 17:38:22 +00:00
|
|
|
rcu_read_unlock();
|
2010-10-23 11:09:06 +00:00
|
|
|
return NULL;
|
2008-10-30 06:35:24 +00:00
|
|
|
}
|
|
|
|
|
2010-10-23 15:18:01 +00:00
|
|
|
/*
|
|
|
|
* Each cpu owns a range of LAST_INO_BATCH numbers.
|
|
|
|
* 'shared_last_ino' is dirtied only once out of LAST_INO_BATCH allocations,
|
|
|
|
* to renew the exhausted range.
|
2008-10-30 06:35:24 +00:00
|
|
|
*
|
2010-10-23 15:18:01 +00:00
|
|
|
* This does not significantly increase overflow rate because every CPU can
|
|
|
|
* consume at most LAST_INO_BATCH-1 unused inode numbers. So there is
|
|
|
|
* NR_CPUS*(LAST_INO_BATCH-1) wastage. At 4096 and 1024, this is ~0.1% of the
|
|
|
|
* 2^32 range, and is a worst-case. Even a 50% wastage would only increase
|
|
|
|
* overflow rate by 2x, which does not seem too significant.
|
|
|
|
*
|
|
|
|
* On a 32bit, non LFS stat() call, glibc will generate an EOVERFLOW
|
|
|
|
* error if st_ino won't fit in target struct field. Use 32bit counter
|
|
|
|
* here to attempt to avoid that.
|
2008-10-30 06:35:24 +00:00
|
|
|
*/
|
2010-10-23 15:18:01 +00:00
|
|
|
#define LAST_INO_BATCH 1024
|
|
|
|
static DEFINE_PER_CPU(unsigned int, last_ino);
|
|
|
|
|
2010-10-23 15:19:54 +00:00
|
|
|
unsigned int get_next_ino(void)
|
2008-10-30 06:35:24 +00:00
|
|
|
{
|
2010-10-23 15:18:01 +00:00
|
|
|
unsigned int *p = &get_cpu_var(last_ino);
|
|
|
|
unsigned int res = *p;
|
2008-10-30 06:35:24 +00:00
|
|
|
|
2010-10-23 15:18:01 +00:00
|
|
|
#ifdef CONFIG_SMP
|
|
|
|
if (unlikely((res & (LAST_INO_BATCH-1)) == 0)) {
|
|
|
|
static atomic_t shared_last_ino;
|
|
|
|
int next = atomic_add_return(LAST_INO_BATCH, &shared_last_ino);
|
|
|
|
|
|
|
|
res = next - LAST_INO_BATCH;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
vfs: avoid creation of inode number 0 in get_next_ino
currently, get_next_ino() is able to create inodes with inode number = 0.
This have a bad impact in the filesystems relying in this function to generate
inode numbers.
While there is no problem at all in having inodes with number 0, userspace tools
which handle file management tasks can have problems handling these files, like
for example, the impossiblity of users to delete these files, since glibc will
ignore them. So, I believe the best way is kernel to avoid creating them.
This problem has been raised previously, but the old thread didn't have any
other update for a year+, and I've seen too many users hitting the same issue
regarding the impossibility to delete files while using filesystems relying on
this function. So, I'm starting the thread again, with the same patch
that I believe is enough to address this problem.
Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-06-25 15:25:58 +00:00
|
|
|
res++;
|
|
|
|
/* get_next_ino should not provide a 0 inode number */
|
|
|
|
if (unlikely(!res))
|
|
|
|
res++;
|
|
|
|
*p = res;
|
2010-10-23 15:18:01 +00:00
|
|
|
put_cpu_var(last_ino);
|
|
|
|
return res;
|
2008-10-30 06:35:24 +00:00
|
|
|
}
|
2010-10-23 15:19:54 +00:00
|
|
|
EXPORT_SYMBOL(get_next_ino);
|
2008-10-30 06:35:24 +00:00
|
|
|
|
2011-07-26 09:36:34 +00:00
|
|
|
/**
|
|
|
|
* new_inode_pseudo - obtain an inode
|
|
|
|
* @sb: superblock
|
|
|
|
*
|
|
|
|
* Allocates a new inode for given superblock.
|
|
|
|
* Inode wont be chained in superblock s_inodes list
|
|
|
|
* This means :
|
|
|
|
* - fs can't be unmount
|
|
|
|
* - quotas, fsnotify, writeback can't work
|
|
|
|
*/
|
|
|
|
struct inode *new_inode_pseudo(struct super_block *sb)
|
|
|
|
{
|
2024-06-11 12:06:24 +00:00
|
|
|
return alloc_inode(sb);
|
2011-07-26 09:36:34 +00:00
|
|
|
}
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/**
|
|
|
|
* new_inode - obtain an inode
|
|
|
|
* @sb: superblock
|
|
|
|
*
|
2007-07-17 11:03:05 +00:00
|
|
|
* Allocates a new inode for given superblock. The default gfp_mask
|
2009-01-06 22:39:23 +00:00
|
|
|
* for allocations related to inode->i_mapping is GFP_HIGHUSER_MOVABLE.
|
2007-07-17 11:03:05 +00:00
|
|
|
* If HIGHMEM pages are unsuitable or it is known that pages allocated
|
|
|
|
* for the page cache are not reclaimable or migratable,
|
|
|
|
* mapping_set_gfp_mask() must be called with suitable flags on the
|
|
|
|
* newly created inode's mapping
|
|
|
|
*
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
|
|
|
struct inode *new_inode(struct super_block *sb)
|
|
|
|
{
|
2009-03-31 14:05:54 +00:00
|
|
|
struct inode *inode;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2011-07-26 09:36:34 +00:00
|
|
|
inode = new_inode_pseudo(sb);
|
|
|
|
if (inode)
|
2011-03-22 11:23:40 +00:00
|
|
|
inode_sb_list_add(inode);
|
2005-04-16 22:20:36 +00:00
|
|
|
return inode;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(new_inode);
|
|
|
|
|
2007-10-13 23:38:33 +00:00
|
|
|
#ifdef CONFIG_DEBUG_LOCK_ALLOC
|
lockdep: Add helper function for dir vs file i_mutex annotation
Purely in-memory filesystems do not use the inode hash as the dcache
tells us if an entry already exists. As a result, they do not call
unlock_new_inode, and thus directory inodes do not get put into a
different lockdep class for i_sem.
We need the different lockdep classes, because the locking order for
i_mutex is different for directory inodes and regular inodes. Directory
inodes can do "readdir()", which takes i_mutex *before* possibly taking
mm->mmap_sem (due to a page fault while copying the directory entry to
user space).
In contrast, regular inodes can be mmap'ed, which takes mm->mmap_sem
before accessing i_mutex.
The two cases can never happen for the same inode, so no real deadlock
can occur, but without the different lockdep classes, lockdep cannot
understand that. As a result, if CONFIG_DEBUG_LOCK_ALLOC is set, this
can lead to false positives from lockdep like below:
find/645 is trying to acquire lock:
(&mm->mmap_sem){++++++}, at: [<ffffffff81109514>] might_fault+0x5c/0xac
but task is already holding lock:
(&sb->s_type->i_mutex_key#15){+.+.+.}, at: [<ffffffff81149f34>]
vfs_readdir+0x5b/0xb4
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&sb->s_type->i_mutex_key#15){+.+.+.}:
[<ffffffff8108ac26>] lock_acquire+0xbf/0x103
[<ffffffff814db822>] __mutex_lock_common+0x4c/0x361
[<ffffffff814dbc46>] mutex_lock_nested+0x40/0x45
[<ffffffff811daa87>] hugetlbfs_file_mmap+0x82/0x110
[<ffffffff81111557>] mmap_region+0x258/0x432
[<ffffffff811119dd>] do_mmap_pgoff+0x2ac/0x306
[<ffffffff81111b4f>] sys_mmap_pgoff+0x118/0x16a
[<ffffffff8100c858>] sys_mmap+0x22/0x24
[<ffffffff814e3ec2>] system_call_fastpath+0x16/0x1b
-> #0 (&mm->mmap_sem){++++++}:
[<ffffffff8108a4bc>] __lock_acquire+0xa1a/0xcf7
[<ffffffff8108ac26>] lock_acquire+0xbf/0x103
[<ffffffff81109541>] might_fault+0x89/0xac
[<ffffffff81149cff>] filldir+0x6f/0xc7
[<ffffffff811586ea>] dcache_readdir+0x67/0x205
[<ffffffff81149f54>] vfs_readdir+0x7b/0xb4
[<ffffffff8114a073>] sys_getdents+0x7e/0xd1
[<ffffffff814e3ec2>] system_call_fastpath+0x16/0x1b
This patch moves the directory vs file lockdep annotation into a helper
function that can be called by in-memory filesystems and has hugetlbfs
call it.
Signed-off-by: Josh Boyer <jwboyer@redhat.com>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-08-25 11:48:12 +00:00
|
|
|
void lockdep_annotate_inode_mutex_key(struct inode *inode)
|
|
|
|
{
|
2010-10-11 13:38:00 +00:00
|
|
|
if (S_ISDIR(inode->i_mode)) {
|
2007-10-16 04:47:54 +00:00
|
|
|
struct file_system_type *type = inode->i_sb->s_type;
|
|
|
|
|
2009-06-04 13:26:49 +00:00
|
|
|
/* Set new key only if filesystem hasn't already changed it */
|
2016-04-15 19:08:36 +00:00
|
|
|
if (lockdep_match_class(&inode->i_rwsem, &type->i_mutex_key)) {
|
2009-06-04 13:26:49 +00:00
|
|
|
/*
|
|
|
|
* ensure nobody is actually holding i_mutex
|
|
|
|
*/
|
2016-04-15 19:08:36 +00:00
|
|
|
// mutex_destroy(&inode->i_mutex);
|
|
|
|
init_rwsem(&inode->i_rwsem);
|
|
|
|
lockdep_set_class(&inode->i_rwsem,
|
2009-06-04 13:26:49 +00:00
|
|
|
&type->i_mutex_dir_key);
|
|
|
|
}
|
2007-10-16 04:47:54 +00:00
|
|
|
}
|
lockdep: Add helper function for dir vs file i_mutex annotation
Purely in-memory filesystems do not use the inode hash as the dcache
tells us if an entry already exists. As a result, they do not call
unlock_new_inode, and thus directory inodes do not get put into a
different lockdep class for i_sem.
We need the different lockdep classes, because the locking order for
i_mutex is different for directory inodes and regular inodes. Directory
inodes can do "readdir()", which takes i_mutex *before* possibly taking
mm->mmap_sem (due to a page fault while copying the directory entry to
user space).
In contrast, regular inodes can be mmap'ed, which takes mm->mmap_sem
before accessing i_mutex.
The two cases can never happen for the same inode, so no real deadlock
can occur, but without the different lockdep classes, lockdep cannot
understand that. As a result, if CONFIG_DEBUG_LOCK_ALLOC is set, this
can lead to false positives from lockdep like below:
find/645 is trying to acquire lock:
(&mm->mmap_sem){++++++}, at: [<ffffffff81109514>] might_fault+0x5c/0xac
but task is already holding lock:
(&sb->s_type->i_mutex_key#15){+.+.+.}, at: [<ffffffff81149f34>]
vfs_readdir+0x5b/0xb4
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&sb->s_type->i_mutex_key#15){+.+.+.}:
[<ffffffff8108ac26>] lock_acquire+0xbf/0x103
[<ffffffff814db822>] __mutex_lock_common+0x4c/0x361
[<ffffffff814dbc46>] mutex_lock_nested+0x40/0x45
[<ffffffff811daa87>] hugetlbfs_file_mmap+0x82/0x110
[<ffffffff81111557>] mmap_region+0x258/0x432
[<ffffffff811119dd>] do_mmap_pgoff+0x2ac/0x306
[<ffffffff81111b4f>] sys_mmap_pgoff+0x118/0x16a
[<ffffffff8100c858>] sys_mmap+0x22/0x24
[<ffffffff814e3ec2>] system_call_fastpath+0x16/0x1b
-> #0 (&mm->mmap_sem){++++++}:
[<ffffffff8108a4bc>] __lock_acquire+0xa1a/0xcf7
[<ffffffff8108ac26>] lock_acquire+0xbf/0x103
[<ffffffff81109541>] might_fault+0x89/0xac
[<ffffffff81149cff>] filldir+0x6f/0xc7
[<ffffffff811586ea>] dcache_readdir+0x67/0x205
[<ffffffff81149f54>] vfs_readdir+0x7b/0xb4
[<ffffffff8114a073>] sys_getdents+0x7e/0xd1
[<ffffffff814e3ec2>] system_call_fastpath+0x16/0x1b
This patch moves the directory vs file lockdep annotation into a helper
function that can be called by in-memory filesystems and has hugetlbfs
call it.
Signed-off-by: Josh Boyer <jwboyer@redhat.com>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-08-25 11:48:12 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(lockdep_annotate_inode_mutex_key);
|
2007-10-13 23:38:33 +00:00
|
|
|
#endif
|
lockdep: Add helper function for dir vs file i_mutex annotation
Purely in-memory filesystems do not use the inode hash as the dcache
tells us if an entry already exists. As a result, they do not call
unlock_new_inode, and thus directory inodes do not get put into a
different lockdep class for i_sem.
We need the different lockdep classes, because the locking order for
i_mutex is different for directory inodes and regular inodes. Directory
inodes can do "readdir()", which takes i_mutex *before* possibly taking
mm->mmap_sem (due to a page fault while copying the directory entry to
user space).
In contrast, regular inodes can be mmap'ed, which takes mm->mmap_sem
before accessing i_mutex.
The two cases can never happen for the same inode, so no real deadlock
can occur, but without the different lockdep classes, lockdep cannot
understand that. As a result, if CONFIG_DEBUG_LOCK_ALLOC is set, this
can lead to false positives from lockdep like below:
find/645 is trying to acquire lock:
(&mm->mmap_sem){++++++}, at: [<ffffffff81109514>] might_fault+0x5c/0xac
but task is already holding lock:
(&sb->s_type->i_mutex_key#15){+.+.+.}, at: [<ffffffff81149f34>]
vfs_readdir+0x5b/0xb4
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&sb->s_type->i_mutex_key#15){+.+.+.}:
[<ffffffff8108ac26>] lock_acquire+0xbf/0x103
[<ffffffff814db822>] __mutex_lock_common+0x4c/0x361
[<ffffffff814dbc46>] mutex_lock_nested+0x40/0x45
[<ffffffff811daa87>] hugetlbfs_file_mmap+0x82/0x110
[<ffffffff81111557>] mmap_region+0x258/0x432
[<ffffffff811119dd>] do_mmap_pgoff+0x2ac/0x306
[<ffffffff81111b4f>] sys_mmap_pgoff+0x118/0x16a
[<ffffffff8100c858>] sys_mmap+0x22/0x24
[<ffffffff814e3ec2>] system_call_fastpath+0x16/0x1b
-> #0 (&mm->mmap_sem){++++++}:
[<ffffffff8108a4bc>] __lock_acquire+0xa1a/0xcf7
[<ffffffff8108ac26>] lock_acquire+0xbf/0x103
[<ffffffff81109541>] might_fault+0x89/0xac
[<ffffffff81149cff>] filldir+0x6f/0xc7
[<ffffffff811586ea>] dcache_readdir+0x67/0x205
[<ffffffff81149f54>] vfs_readdir+0x7b/0xb4
[<ffffffff8114a073>] sys_getdents+0x7e/0xd1
[<ffffffff814e3ec2>] system_call_fastpath+0x16/0x1b
This patch moves the directory vs file lockdep annotation into a helper
function that can be called by in-memory filesystems and has hugetlbfs
call it.
Signed-off-by: Josh Boyer <jwboyer@redhat.com>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-08-25 11:48:12 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* unlock_new_inode - clear the I_NEW state and wake up any waiters
|
|
|
|
* @inode: new inode to unlock
|
|
|
|
*
|
|
|
|
* Called when the inode is fully initialised to clear the new state of the
|
|
|
|
* inode and wake up anyone waiting for the inode to finish initialisation.
|
|
|
|
*/
|
|
|
|
void unlock_new_inode(struct inode *inode)
|
|
|
|
{
|
|
|
|
lockdep_annotate_inode_mutex_key(inode);
|
2011-03-22 11:23:36 +00:00
|
|
|
spin_lock(&inode->i_lock);
|
2009-12-17 13:25:01 +00:00
|
|
|
WARN_ON(!(inode->i_state & I_NEW));
|
2018-06-28 19:53:17 +00:00
|
|
|
inode->i_state &= ~I_NEW & ~I_CREATING;
|
2024-08-23 12:47:38 +00:00
|
|
|
/*
|
|
|
|
* Pairs with the barrier in prepare_to_wait_event() to make sure
|
|
|
|
* ___wait_var_event() either sees the bit cleared or
|
|
|
|
* waitqueue_active() check in wake_up_var() sees the waiter.
|
|
|
|
*/
|
2012-03-10 22:07:28 +00:00
|
|
|
smp_mb();
|
2024-08-23 12:47:38 +00:00
|
|
|
inode_wake_up_bit(inode, __I_NEW);
|
2011-03-22 11:23:36 +00:00
|
|
|
spin_unlock(&inode->i_lock);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(unlock_new_inode);
|
|
|
|
|
2018-06-28 19:53:17 +00:00
|
|
|
void discard_new_inode(struct inode *inode)
|
|
|
|
{
|
|
|
|
lockdep_annotate_inode_mutex_key(inode);
|
|
|
|
spin_lock(&inode->i_lock);
|
|
|
|
WARN_ON(!(inode->i_state & I_NEW));
|
|
|
|
inode->i_state &= ~I_NEW;
|
2024-08-23 12:47:38 +00:00
|
|
|
/*
|
|
|
|
* Pairs with the barrier in prepare_to_wait_event() to make sure
|
|
|
|
* ___wait_var_event() either sees the bit cleared or
|
|
|
|
* waitqueue_active() check in wake_up_var() sees the waiter.
|
|
|
|
*/
|
2018-06-28 19:53:17 +00:00
|
|
|
smp_mb();
|
2024-08-23 12:47:38 +00:00
|
|
|
inode_wake_up_bit(inode, __I_NEW);
|
2018-06-28 19:53:17 +00:00
|
|
|
spin_unlock(&inode->i_lock);
|
|
|
|
iput(inode);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(discard_new_inode);
|
|
|
|
|
2012-04-18 19:16:33 +00:00
|
|
|
/**
|
|
|
|
* lock_two_nondirectories - take two i_mutexes on non-directory objects
|
2014-04-01 15:08:43 +00:00
|
|
|
*
|
2023-06-01 10:58:26 +00:00
|
|
|
* Lock any non-NULL argument. Passed objects must not be directories.
|
2014-04-01 15:08:43 +00:00
|
|
|
* Zero, one or two objects may be locked by this function.
|
|
|
|
*
|
2012-04-18 19:16:33 +00:00
|
|
|
* @inode1: first inode to lock
|
|
|
|
* @inode2: second inode to lock
|
|
|
|
*/
|
|
|
|
void lock_two_nondirectories(struct inode *inode1, struct inode *inode2)
|
|
|
|
{
|
2023-07-03 14:49:12 +00:00
|
|
|
if (inode1)
|
|
|
|
WARN_ON_ONCE(S_ISDIR(inode1->i_mode));
|
|
|
|
if (inode2)
|
|
|
|
WARN_ON_ONCE(S_ISDIR(inode2->i_mode));
|
2023-11-20 03:21:00 +00:00
|
|
|
if (inode1 > inode2)
|
|
|
|
swap(inode1, inode2);
|
|
|
|
if (inode1)
|
|
|
|
inode_lock(inode1);
|
|
|
|
if (inode2 && inode2 != inode1)
|
|
|
|
inode_lock_nested(inode2, I_MUTEX_NONDIR2);
|
2012-04-18 19:16:33 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(lock_two_nondirectories);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* unlock_two_nondirectories - release locks from lock_two_nondirectories()
|
|
|
|
* @inode1: first inode to unlock
|
|
|
|
* @inode2: second inode to unlock
|
|
|
|
*/
|
|
|
|
void unlock_two_nondirectories(struct inode *inode1, struct inode *inode2)
|
|
|
|
{
|
2023-06-01 10:58:26 +00:00
|
|
|
if (inode1) {
|
|
|
|
WARN_ON_ONCE(S_ISDIR(inode1->i_mode));
|
2016-01-22 20:40:57 +00:00
|
|
|
inode_unlock(inode1);
|
2023-06-01 10:58:26 +00:00
|
|
|
}
|
|
|
|
if (inode2 && inode2 != inode1) {
|
|
|
|
WARN_ON_ONCE(S_ISDIR(inode2->i_mode));
|
2016-01-22 20:40:57 +00:00
|
|
|
inode_unlock(inode2);
|
2023-06-01 10:58:26 +00:00
|
|
|
}
|
2012-04-18 19:16:33 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(unlock_two_nondirectories);
|
|
|
|
|
2018-05-17 08:53:05 +00:00
|
|
|
/**
|
|
|
|
* inode_insert5 - obtain an inode from a mounted file system
|
|
|
|
* @inode: pre-allocated inode to use for insert to cache
|
|
|
|
* @hashval: hash value (usually inode number) to get
|
|
|
|
* @test: callback used for comparisons between inodes
|
|
|
|
* @set: callback used to initialize a new struct inode
|
|
|
|
* @data: opaque data pointer to pass to @test and @set
|
|
|
|
*
|
|
|
|
* Search for the inode specified by @hashval and @data in the inode cache,
|
2024-10-04 11:51:51 +00:00
|
|
|
* and if present return it with an increased reference count. This is a
|
|
|
|
* variant of iget5_locked() that doesn't allocate an inode.
|
2018-05-17 08:53:05 +00:00
|
|
|
*
|
2024-10-04 11:51:51 +00:00
|
|
|
* If the inode is not present in the cache, insert the pre-allocated inode and
|
2018-05-17 08:53:05 +00:00
|
|
|
* return it locked, hashed, and with the I_NEW flag set. The file system gets
|
|
|
|
* to fill it in before unlocking it via unlock_new_inode().
|
|
|
|
*
|
2024-10-04 11:51:51 +00:00
|
|
|
* Note that both @test and @set are called with the inode_hash_lock held, so
|
|
|
|
* they can't sleep.
|
2018-05-17 08:53:05 +00:00
|
|
|
*/
|
|
|
|
struct inode *inode_insert5(struct inode *inode, unsigned long hashval,
|
|
|
|
int (*test)(struct inode *, void *),
|
|
|
|
int (*set)(struct inode *, void *), void *data)
|
|
|
|
{
|
|
|
|
struct hlist_head *head = inode_hashtable + hash(inode->i_sb, hashval);
|
|
|
|
struct inode *old;
|
|
|
|
|
|
|
|
again:
|
|
|
|
spin_lock(&inode_hash_lock);
|
vfs: add rcu-based find_inode variants for iget ops
This avoids one inode hash lock acquire in the common case on inode
creation, in effect significantly reducing contention.
On the stock kernel said lock is typically taken twice:
1. once to check if the inode happens to already be present
2. once to add it to the hash
The back-to-back lock/unlock pattern is known to degrade performance
significantly, which is further exacerbated if the hash is heavily
populated (long chains to walk, extending hold time). Arguably hash
sizing and hashing algo need to be revisited, but that's beyond the
scope of this patch.
With the acquire from step 1 eliminated with RCU lookup throughput
increases significantly at the scale of 20 cores (benchmark results at
the bottom).
So happens the hash already supports RCU-based operation, but lookups on
inode insertions didn't take advantage of it.
This of course has its limits as the global lock is still a bottleneck.
There was a patchset posted which introduced fine-grained locking[1] but
it appears staled. Apart from that doubt was expressed whether a
handrolled hash implementation is appropriate to begin with, suggesting
replacement with rhashtables. Nobody committed to carrying [1] across
the finish line or implementing anything better, thus the bandaid below.
iget_locked consumers (notably ext4) get away without any changes
because inode comparison method is built-in.
iget5_locked consumers pass a custom callback. Since removal of locking
adds more problems (inode can be changing) it's not safe to assume all
filesystems happen to cope. Thus iget5_locked_rcu gets added, requiring
manual conversion of interested filesystems.
In order to reduce code duplication find_inode and find_inode_fast grow
an argument indicating whether inode hash lock is held, which is passed
down in case sleeping is necessary. They always rcu_read_lock, which is
redundant but harmless. Doing it conditionally reduces readability for
no real gain that I can see. RCU-alike restrictions were already put on
callbacks due to the hash spinlock being held.
Benchmarking:
There is a real cache-busting workload scanning millions of files in
parallel (it's a backup appliance), where the initial lookup is
guaranteed to fail resulting in the two lock acquires on stock kernel
(and one with the patch at hand).
Implemented below is a synthetic benchmark providing the same behavior.
[I shall note the workload is not running on Linux, instead it was
causing trouble elsewhere. Benchmark below was used while addressing
said problems and was found to adequately represent the real workload.]
Total real time fluctuates by 1-2s.
With 20 threads each walking a dedicated 1000 dirs * 1000 files
directory tree to stat(2) on a 32 core + 24GB RAM vm:
ext4 (needed mkfs.ext4 -N 24000000):
before: 3.77s user 890.90s system 1939% cpu 46.118 total
after: 3.24s user 397.73s system 1858% cpu 21.581 total (-53%)
That's 20 million files to visit, while the machine can only cache about
15 million at a time (obtained from ext4_inode_cache object count in
/proc/slabinfo). Since each terminal inode is only visited once per run
this amounts to 0% hit ratio for the dentry cache and the hash table
(there are however hits for the intermediate directories).
On repeated runs the kernel caches the last ~15 mln, meaning there is ~5
mln of uncached inodes which are going to be visited first, evicting the
previously cached state as it happens.
Lack of hits can be trivially verified with bpftrace, like so:
bpftrace -e 'kretprobe:find_inode_fast { @[kstack(), retval != 0] = count(); }'\
-c "/bin/sh walktrees /testfs 20"
Best ran more than once.
Expected results after "warmup":
[snip]
@[
__ext4_iget+275
ext4_lookup+224
__lookup_slow+130
walk_component+219
link_path_walk.part.0.constprop.0+614
path_lookupat+62
filename_lookup+204
vfs_statx+128
vfs_fstatat+131
__do_sys_newfstatat+38
do_syscall_64+87
entry_SYSCALL_64_after_hwframe+118
, 1]: 20000
@[
__ext4_iget+275
ext4_lookup+224
__lookup_slow+130
walk_component+219
path_lookupat+106
filename_lookup+204
vfs_statx+128
vfs_fstatat+131
__do_sys_newfstatat+38
do_syscall_64+87
entry_SYSCALL_64_after_hwframe+118
, 1]: 20000000
That is 20 million calls for the initial lookup and 20 million after
allocating a new inode, all of them failing to return a value != 0
(i.e., they are returning NULL -- no match found).
Of course aborting the benchmark in the middle and starting it again (or
messing with the state in other ways) is going to alter these results.
Benchmark can be found here: https://people.freebsd.org/~mjg/fstree.tgz
[1] https://lore.kernel.org/all/20231206060629.2827226-1-david@fromorbit.com/
Signed-off-by: Mateusz Guzik <mjguzik@gmail.com>
Link: https://lore.kernel.org/r/20240611173824.535995-2-mjguzik@gmail.com
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-06-11 17:38:22 +00:00
|
|
|
old = find_inode(inode->i_sb, head, test, data, true);
|
2018-05-17 08:53:05 +00:00
|
|
|
if (unlikely(old)) {
|
|
|
|
/*
|
|
|
|
* Uhhuh, somebody else created the same inode under us.
|
|
|
|
* Use the old inode instead of the preallocated one.
|
|
|
|
*/
|
|
|
|
spin_unlock(&inode_hash_lock);
|
2018-06-28 19:53:17 +00:00
|
|
|
if (IS_ERR(old))
|
|
|
|
return NULL;
|
2018-05-17 08:53:05 +00:00
|
|
|
wait_on_inode(old);
|
|
|
|
if (unlikely(inode_unhashed(old))) {
|
|
|
|
iput(old);
|
|
|
|
goto again;
|
|
|
|
}
|
|
|
|
return old;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (set && unlikely(set(inode, data))) {
|
|
|
|
inode = NULL;
|
|
|
|
goto unlock;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Return the locked inode with I_NEW set, the
|
|
|
|
* caller is responsible for filling in the contents
|
|
|
|
*/
|
|
|
|
spin_lock(&inode->i_lock);
|
|
|
|
inode->i_state |= I_NEW;
|
2017-12-01 11:40:16 +00:00
|
|
|
hlist_add_head_rcu(&inode->i_hash, head);
|
2018-05-17 08:53:05 +00:00
|
|
|
spin_unlock(&inode->i_lock);
|
2022-03-31 20:29:00 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Add inode to the sb list if it's not already. It has I_NEW at this
|
|
|
|
* point, so it should be safe to test i_sb_list locklessly.
|
|
|
|
*/
|
|
|
|
if (list_empty(&inode->i_sb_list))
|
2018-07-24 13:01:55 +00:00
|
|
|
inode_sb_list_add(inode);
|
2018-05-17 08:53:05 +00:00
|
|
|
unlock:
|
|
|
|
spin_unlock(&inode_hash_lock);
|
|
|
|
|
|
|
|
return inode;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(inode_insert5);
|
|
|
|
|
2011-03-23 19:03:28 +00:00
|
|
|
/**
|
|
|
|
* iget5_locked - obtain an inode from a mounted file system
|
|
|
|
* @sb: super block of file system
|
|
|
|
* @hashval: hash value (usually inode number) to get
|
|
|
|
* @test: callback used for comparisons between inodes
|
|
|
|
* @set: callback used to initialize a new struct inode
|
|
|
|
* @data: opaque data pointer to pass to @test and @set
|
|
|
|
*
|
|
|
|
* Search for the inode specified by @hashval and @data in the inode cache,
|
2024-10-04 11:51:51 +00:00
|
|
|
* and if present return it with an increased reference count. This is a
|
|
|
|
* generalized version of iget_locked() for file systems where the inode
|
2011-03-23 19:03:28 +00:00
|
|
|
* number is not sufficient for unique identification of an inode.
|
|
|
|
*
|
2024-10-04 11:51:51 +00:00
|
|
|
* If the inode is not present in the cache, allocate and insert a new inode
|
|
|
|
* and return it locked, hashed, and with the I_NEW flag set. The file system
|
|
|
|
* gets to fill it in before unlocking it via unlock_new_inode().
|
2005-04-16 22:20:36 +00:00
|
|
|
*
|
2024-10-04 11:51:51 +00:00
|
|
|
* Note that both @test and @set are called with the inode_hash_lock held, so
|
|
|
|
* they can't sleep.
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
2011-03-23 19:03:28 +00:00
|
|
|
struct inode *iget5_locked(struct super_block *sb, unsigned long hashval,
|
|
|
|
int (*test)(struct inode *, void *),
|
|
|
|
int (*set)(struct inode *, void *), void *data)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2018-05-17 08:53:05 +00:00
|
|
|
struct inode *inode = ilookup5(sb, hashval, test, data);
|
2011-03-23 19:03:28 +00:00
|
|
|
|
2018-05-17 08:53:05 +00:00
|
|
|
if (!inode) {
|
2018-07-24 13:01:55 +00:00
|
|
|
struct inode *new = alloc_inode(sb);
|
2011-03-23 19:03:28 +00:00
|
|
|
|
2018-05-17 08:53:05 +00:00
|
|
|
if (new) {
|
|
|
|
inode = inode_insert5(new, hashval, test, set, data);
|
|
|
|
if (unlikely(inode != new))
|
2018-07-24 13:01:55 +00:00
|
|
|
destroy_inode(new);
|
2016-07-04 03:15:21 +00:00
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
return inode;
|
|
|
|
}
|
2011-03-23 19:03:28 +00:00
|
|
|
EXPORT_SYMBOL(iget5_locked);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
vfs: add rcu-based find_inode variants for iget ops
This avoids one inode hash lock acquire in the common case on inode
creation, in effect significantly reducing contention.
On the stock kernel said lock is typically taken twice:
1. once to check if the inode happens to already be present
2. once to add it to the hash
The back-to-back lock/unlock pattern is known to degrade performance
significantly, which is further exacerbated if the hash is heavily
populated (long chains to walk, extending hold time). Arguably hash
sizing and hashing algo need to be revisited, but that's beyond the
scope of this patch.
With the acquire from step 1 eliminated with RCU lookup throughput
increases significantly at the scale of 20 cores (benchmark results at
the bottom).
So happens the hash already supports RCU-based operation, but lookups on
inode insertions didn't take advantage of it.
This of course has its limits as the global lock is still a bottleneck.
There was a patchset posted which introduced fine-grained locking[1] but
it appears staled. Apart from that doubt was expressed whether a
handrolled hash implementation is appropriate to begin with, suggesting
replacement with rhashtables. Nobody committed to carrying [1] across
the finish line or implementing anything better, thus the bandaid below.
iget_locked consumers (notably ext4) get away without any changes
because inode comparison method is built-in.
iget5_locked consumers pass a custom callback. Since removal of locking
adds more problems (inode can be changing) it's not safe to assume all
filesystems happen to cope. Thus iget5_locked_rcu gets added, requiring
manual conversion of interested filesystems.
In order to reduce code duplication find_inode and find_inode_fast grow
an argument indicating whether inode hash lock is held, which is passed
down in case sleeping is necessary. They always rcu_read_lock, which is
redundant but harmless. Doing it conditionally reduces readability for
no real gain that I can see. RCU-alike restrictions were already put on
callbacks due to the hash spinlock being held.
Benchmarking:
There is a real cache-busting workload scanning millions of files in
parallel (it's a backup appliance), where the initial lookup is
guaranteed to fail resulting in the two lock acquires on stock kernel
(and one with the patch at hand).
Implemented below is a synthetic benchmark providing the same behavior.
[I shall note the workload is not running on Linux, instead it was
causing trouble elsewhere. Benchmark below was used while addressing
said problems and was found to adequately represent the real workload.]
Total real time fluctuates by 1-2s.
With 20 threads each walking a dedicated 1000 dirs * 1000 files
directory tree to stat(2) on a 32 core + 24GB RAM vm:
ext4 (needed mkfs.ext4 -N 24000000):
before: 3.77s user 890.90s system 1939% cpu 46.118 total
after: 3.24s user 397.73s system 1858% cpu 21.581 total (-53%)
That's 20 million files to visit, while the machine can only cache about
15 million at a time (obtained from ext4_inode_cache object count in
/proc/slabinfo). Since each terminal inode is only visited once per run
this amounts to 0% hit ratio for the dentry cache and the hash table
(there are however hits for the intermediate directories).
On repeated runs the kernel caches the last ~15 mln, meaning there is ~5
mln of uncached inodes which are going to be visited first, evicting the
previously cached state as it happens.
Lack of hits can be trivially verified with bpftrace, like so:
bpftrace -e 'kretprobe:find_inode_fast { @[kstack(), retval != 0] = count(); }'\
-c "/bin/sh walktrees /testfs 20"
Best ran more than once.
Expected results after "warmup":
[snip]
@[
__ext4_iget+275
ext4_lookup+224
__lookup_slow+130
walk_component+219
link_path_walk.part.0.constprop.0+614
path_lookupat+62
filename_lookup+204
vfs_statx+128
vfs_fstatat+131
__do_sys_newfstatat+38
do_syscall_64+87
entry_SYSCALL_64_after_hwframe+118
, 1]: 20000
@[
__ext4_iget+275
ext4_lookup+224
__lookup_slow+130
walk_component+219
path_lookupat+106
filename_lookup+204
vfs_statx+128
vfs_fstatat+131
__do_sys_newfstatat+38
do_syscall_64+87
entry_SYSCALL_64_after_hwframe+118
, 1]: 20000000
That is 20 million calls for the initial lookup and 20 million after
allocating a new inode, all of them failing to return a value != 0
(i.e., they are returning NULL -- no match found).
Of course aborting the benchmark in the middle and starting it again (or
messing with the state in other ways) is going to alter these results.
Benchmark can be found here: https://people.freebsd.org/~mjg/fstree.tgz
[1] https://lore.kernel.org/all/20231206060629.2827226-1-david@fromorbit.com/
Signed-off-by: Mateusz Guzik <mjguzik@gmail.com>
Link: https://lore.kernel.org/r/20240611173824.535995-2-mjguzik@gmail.com
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-06-11 17:38:22 +00:00
|
|
|
/**
|
|
|
|
* iget5_locked_rcu - obtain an inode from a mounted file system
|
|
|
|
* @sb: super block of file system
|
|
|
|
* @hashval: hash value (usually inode number) to get
|
|
|
|
* @test: callback used for comparisons between inodes
|
|
|
|
* @set: callback used to initialize a new struct inode
|
|
|
|
* @data: opaque data pointer to pass to @test and @set
|
|
|
|
*
|
|
|
|
* This is equivalent to iget5_locked, except the @test callback must
|
|
|
|
* tolerate the inode not being stable, including being mid-teardown.
|
|
|
|
*/
|
|
|
|
struct inode *iget5_locked_rcu(struct super_block *sb, unsigned long hashval,
|
|
|
|
int (*test)(struct inode *, void *),
|
|
|
|
int (*set)(struct inode *, void *), void *data)
|
|
|
|
{
|
|
|
|
struct hlist_head *head = inode_hashtable + hash(sb, hashval);
|
|
|
|
struct inode *inode, *new;
|
|
|
|
|
|
|
|
again:
|
|
|
|
inode = find_inode(sb, head, test, data, false);
|
|
|
|
if (inode) {
|
|
|
|
if (IS_ERR(inode))
|
|
|
|
return NULL;
|
|
|
|
wait_on_inode(inode);
|
|
|
|
if (unlikely(inode_unhashed(inode))) {
|
|
|
|
iput(inode);
|
|
|
|
goto again;
|
|
|
|
}
|
|
|
|
return inode;
|
|
|
|
}
|
|
|
|
|
|
|
|
new = alloc_inode(sb);
|
|
|
|
if (new) {
|
|
|
|
inode = inode_insert5(new, hashval, test, set, data);
|
|
|
|
if (unlikely(inode != new))
|
|
|
|
destroy_inode(new);
|
|
|
|
}
|
|
|
|
return inode;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(iget5_locked_rcu);
|
|
|
|
|
2011-03-23 19:03:28 +00:00
|
|
|
/**
|
|
|
|
* iget_locked - obtain an inode from a mounted file system
|
|
|
|
* @sb: super block of file system
|
|
|
|
* @ino: inode number to get
|
|
|
|
*
|
|
|
|
* Search for the inode specified by @ino in the inode cache and if present
|
|
|
|
* return it with an increased reference count. This is for file systems
|
|
|
|
* where the inode number is sufficient for unique identification of an inode.
|
|
|
|
*
|
|
|
|
* If the inode is not in cache, allocate a new inode and return it locked,
|
|
|
|
* hashed, and with the I_NEW flag set. The file system gets to fill it in
|
|
|
|
* before unlocking it via unlock_new_inode().
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
2011-03-23 19:03:28 +00:00
|
|
|
struct inode *iget_locked(struct super_block *sb, unsigned long ino)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2011-03-23 19:03:28 +00:00
|
|
|
struct hlist_head *head = inode_hashtable + hash(sb, ino);
|
2009-03-31 14:05:54 +00:00
|
|
|
struct inode *inode;
|
2016-07-04 03:15:21 +00:00
|
|
|
again:
|
vfs: add rcu-based find_inode variants for iget ops
This avoids one inode hash lock acquire in the common case on inode
creation, in effect significantly reducing contention.
On the stock kernel said lock is typically taken twice:
1. once to check if the inode happens to already be present
2. once to add it to the hash
The back-to-back lock/unlock pattern is known to degrade performance
significantly, which is further exacerbated if the hash is heavily
populated (long chains to walk, extending hold time). Arguably hash
sizing and hashing algo need to be revisited, but that's beyond the
scope of this patch.
With the acquire from step 1 eliminated with RCU lookup throughput
increases significantly at the scale of 20 cores (benchmark results at
the bottom).
So happens the hash already supports RCU-based operation, but lookups on
inode insertions didn't take advantage of it.
This of course has its limits as the global lock is still a bottleneck.
There was a patchset posted which introduced fine-grained locking[1] but
it appears staled. Apart from that doubt was expressed whether a
handrolled hash implementation is appropriate to begin with, suggesting
replacement with rhashtables. Nobody committed to carrying [1] across
the finish line or implementing anything better, thus the bandaid below.
iget_locked consumers (notably ext4) get away without any changes
because inode comparison method is built-in.
iget5_locked consumers pass a custom callback. Since removal of locking
adds more problems (inode can be changing) it's not safe to assume all
filesystems happen to cope. Thus iget5_locked_rcu gets added, requiring
manual conversion of interested filesystems.
In order to reduce code duplication find_inode and find_inode_fast grow
an argument indicating whether inode hash lock is held, which is passed
down in case sleeping is necessary. They always rcu_read_lock, which is
redundant but harmless. Doing it conditionally reduces readability for
no real gain that I can see. RCU-alike restrictions were already put on
callbacks due to the hash spinlock being held.
Benchmarking:
There is a real cache-busting workload scanning millions of files in
parallel (it's a backup appliance), where the initial lookup is
guaranteed to fail resulting in the two lock acquires on stock kernel
(and one with the patch at hand).
Implemented below is a synthetic benchmark providing the same behavior.
[I shall note the workload is not running on Linux, instead it was
causing trouble elsewhere. Benchmark below was used while addressing
said problems and was found to adequately represent the real workload.]
Total real time fluctuates by 1-2s.
With 20 threads each walking a dedicated 1000 dirs * 1000 files
directory tree to stat(2) on a 32 core + 24GB RAM vm:
ext4 (needed mkfs.ext4 -N 24000000):
before: 3.77s user 890.90s system 1939% cpu 46.118 total
after: 3.24s user 397.73s system 1858% cpu 21.581 total (-53%)
That's 20 million files to visit, while the machine can only cache about
15 million at a time (obtained from ext4_inode_cache object count in
/proc/slabinfo). Since each terminal inode is only visited once per run
this amounts to 0% hit ratio for the dentry cache and the hash table
(there are however hits for the intermediate directories).
On repeated runs the kernel caches the last ~15 mln, meaning there is ~5
mln of uncached inodes which are going to be visited first, evicting the
previously cached state as it happens.
Lack of hits can be trivially verified with bpftrace, like so:
bpftrace -e 'kretprobe:find_inode_fast { @[kstack(), retval != 0] = count(); }'\
-c "/bin/sh walktrees /testfs 20"
Best ran more than once.
Expected results after "warmup":
[snip]
@[
__ext4_iget+275
ext4_lookup+224
__lookup_slow+130
walk_component+219
link_path_walk.part.0.constprop.0+614
path_lookupat+62
filename_lookup+204
vfs_statx+128
vfs_fstatat+131
__do_sys_newfstatat+38
do_syscall_64+87
entry_SYSCALL_64_after_hwframe+118
, 1]: 20000
@[
__ext4_iget+275
ext4_lookup+224
__lookup_slow+130
walk_component+219
path_lookupat+106
filename_lookup+204
vfs_statx+128
vfs_fstatat+131
__do_sys_newfstatat+38
do_syscall_64+87
entry_SYSCALL_64_after_hwframe+118
, 1]: 20000000
That is 20 million calls for the initial lookup and 20 million after
allocating a new inode, all of them failing to return a value != 0
(i.e., they are returning NULL -- no match found).
Of course aborting the benchmark in the middle and starting it again (or
messing with the state in other ways) is going to alter these results.
Benchmark can be found here: https://people.freebsd.org/~mjg/fstree.tgz
[1] https://lore.kernel.org/all/20231206060629.2827226-1-david@fromorbit.com/
Signed-off-by: Mateusz Guzik <mjguzik@gmail.com>
Link: https://lore.kernel.org/r/20240611173824.535995-2-mjguzik@gmail.com
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-06-11 17:38:22 +00:00
|
|
|
inode = find_inode_fast(sb, head, ino, false);
|
2011-03-23 19:03:28 +00:00
|
|
|
if (inode) {
|
2018-06-28 19:53:17 +00:00
|
|
|
if (IS_ERR(inode))
|
|
|
|
return NULL;
|
2011-03-23 19:03:28 +00:00
|
|
|
wait_on_inode(inode);
|
2016-07-04 03:15:21 +00:00
|
|
|
if (unlikely(inode_unhashed(inode))) {
|
|
|
|
iput(inode);
|
|
|
|
goto again;
|
|
|
|
}
|
2011-03-23 19:03:28 +00:00
|
|
|
return inode;
|
|
|
|
}
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
inode = alloc_inode(sb);
|
|
|
|
if (inode) {
|
2009-03-31 14:05:54 +00:00
|
|
|
struct inode *old;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2011-03-22 11:23:42 +00:00
|
|
|
spin_lock(&inode_hash_lock);
|
2005-04-16 22:20:36 +00:00
|
|
|
/* We released the lock, so.. */
|
vfs: add rcu-based find_inode variants for iget ops
This avoids one inode hash lock acquire in the common case on inode
creation, in effect significantly reducing contention.
On the stock kernel said lock is typically taken twice:
1. once to check if the inode happens to already be present
2. once to add it to the hash
The back-to-back lock/unlock pattern is known to degrade performance
significantly, which is further exacerbated if the hash is heavily
populated (long chains to walk, extending hold time). Arguably hash
sizing and hashing algo need to be revisited, but that's beyond the
scope of this patch.
With the acquire from step 1 eliminated with RCU lookup throughput
increases significantly at the scale of 20 cores (benchmark results at
the bottom).
So happens the hash already supports RCU-based operation, but lookups on
inode insertions didn't take advantage of it.
This of course has its limits as the global lock is still a bottleneck.
There was a patchset posted which introduced fine-grained locking[1] but
it appears staled. Apart from that doubt was expressed whether a
handrolled hash implementation is appropriate to begin with, suggesting
replacement with rhashtables. Nobody committed to carrying [1] across
the finish line or implementing anything better, thus the bandaid below.
iget_locked consumers (notably ext4) get away without any changes
because inode comparison method is built-in.
iget5_locked consumers pass a custom callback. Since removal of locking
adds more problems (inode can be changing) it's not safe to assume all
filesystems happen to cope. Thus iget5_locked_rcu gets added, requiring
manual conversion of interested filesystems.
In order to reduce code duplication find_inode and find_inode_fast grow
an argument indicating whether inode hash lock is held, which is passed
down in case sleeping is necessary. They always rcu_read_lock, which is
redundant but harmless. Doing it conditionally reduces readability for
no real gain that I can see. RCU-alike restrictions were already put on
callbacks due to the hash spinlock being held.
Benchmarking:
There is a real cache-busting workload scanning millions of files in
parallel (it's a backup appliance), where the initial lookup is
guaranteed to fail resulting in the two lock acquires on stock kernel
(and one with the patch at hand).
Implemented below is a synthetic benchmark providing the same behavior.
[I shall note the workload is not running on Linux, instead it was
causing trouble elsewhere. Benchmark below was used while addressing
said problems and was found to adequately represent the real workload.]
Total real time fluctuates by 1-2s.
With 20 threads each walking a dedicated 1000 dirs * 1000 files
directory tree to stat(2) on a 32 core + 24GB RAM vm:
ext4 (needed mkfs.ext4 -N 24000000):
before: 3.77s user 890.90s system 1939% cpu 46.118 total
after: 3.24s user 397.73s system 1858% cpu 21.581 total (-53%)
That's 20 million files to visit, while the machine can only cache about
15 million at a time (obtained from ext4_inode_cache object count in
/proc/slabinfo). Since each terminal inode is only visited once per run
this amounts to 0% hit ratio for the dentry cache and the hash table
(there are however hits for the intermediate directories).
On repeated runs the kernel caches the last ~15 mln, meaning there is ~5
mln of uncached inodes which are going to be visited first, evicting the
previously cached state as it happens.
Lack of hits can be trivially verified with bpftrace, like so:
bpftrace -e 'kretprobe:find_inode_fast { @[kstack(), retval != 0] = count(); }'\
-c "/bin/sh walktrees /testfs 20"
Best ran more than once.
Expected results after "warmup":
[snip]
@[
__ext4_iget+275
ext4_lookup+224
__lookup_slow+130
walk_component+219
link_path_walk.part.0.constprop.0+614
path_lookupat+62
filename_lookup+204
vfs_statx+128
vfs_fstatat+131
__do_sys_newfstatat+38
do_syscall_64+87
entry_SYSCALL_64_after_hwframe+118
, 1]: 20000
@[
__ext4_iget+275
ext4_lookup+224
__lookup_slow+130
walk_component+219
path_lookupat+106
filename_lookup+204
vfs_statx+128
vfs_fstatat+131
__do_sys_newfstatat+38
do_syscall_64+87
entry_SYSCALL_64_after_hwframe+118
, 1]: 20000000
That is 20 million calls for the initial lookup and 20 million after
allocating a new inode, all of them failing to return a value != 0
(i.e., they are returning NULL -- no match found).
Of course aborting the benchmark in the middle and starting it again (or
messing with the state in other ways) is going to alter these results.
Benchmark can be found here: https://people.freebsd.org/~mjg/fstree.tgz
[1] https://lore.kernel.org/all/20231206060629.2827226-1-david@fromorbit.com/
Signed-off-by: Mateusz Guzik <mjguzik@gmail.com>
Link: https://lore.kernel.org/r/20240611173824.535995-2-mjguzik@gmail.com
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-06-11 17:38:22 +00:00
|
|
|
old = find_inode_fast(sb, head, ino, true);
|
2005-04-16 22:20:36 +00:00
|
|
|
if (!old) {
|
|
|
|
inode->i_ino = ino;
|
2011-03-22 11:23:36 +00:00
|
|
|
spin_lock(&inode->i_lock);
|
|
|
|
inode->i_state = I_NEW;
|
2017-12-01 11:40:16 +00:00
|
|
|
hlist_add_head_rcu(&inode->i_hash, head);
|
2011-03-22 11:23:36 +00:00
|
|
|
spin_unlock(&inode->i_lock);
|
2011-03-22 11:23:40 +00:00
|
|
|
inode_sb_list_add(inode);
|
2011-03-22 11:23:42 +00:00
|
|
|
spin_unlock(&inode_hash_lock);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
/* Return the locked inode with I_NEW set, the
|
|
|
|
* caller is responsible for filling in the contents
|
|
|
|
*/
|
|
|
|
return inode;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Uhhuh, somebody else created the same inode under
|
|
|
|
* us. Use the old inode instead of the one we just
|
|
|
|
* allocated.
|
|
|
|
*/
|
2011-03-22 11:23:42 +00:00
|
|
|
spin_unlock(&inode_hash_lock);
|
2005-04-16 22:20:36 +00:00
|
|
|
destroy_inode(inode);
|
2018-06-28 19:53:17 +00:00
|
|
|
if (IS_ERR(old))
|
|
|
|
return NULL;
|
2005-04-16 22:20:36 +00:00
|
|
|
inode = old;
|
|
|
|
wait_on_inode(inode);
|
2016-07-04 03:15:21 +00:00
|
|
|
if (unlikely(inode_unhashed(inode))) {
|
|
|
|
iput(inode);
|
|
|
|
goto again;
|
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
return inode;
|
|
|
|
}
|
2011-03-23 19:03:28 +00:00
|
|
|
EXPORT_SYMBOL(iget_locked);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2010-10-23 11:00:16 +00:00
|
|
|
/*
|
|
|
|
* search the inode cache for a matching inode number.
|
|
|
|
* If we find one, then the inode number we are trying to
|
|
|
|
* allocate is not unique and so we should not use it.
|
|
|
|
*
|
|
|
|
* Returns 1 if the inode number is unique, 0 if it is not.
|
|
|
|
*/
|
|
|
|
static int test_inode_iunique(struct super_block *sb, unsigned long ino)
|
|
|
|
{
|
|
|
|
struct hlist_head *b = inode_hashtable + hash(sb, ino);
|
|
|
|
struct inode *inode;
|
|
|
|
|
2017-12-01 11:40:16 +00:00
|
|
|
hlist_for_each_entry_rcu(inode, b, i_hash) {
|
|
|
|
if (inode->i_ino == ino && inode->i_sb == sb)
|
2010-10-23 11:00:16 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/**
|
|
|
|
* iunique - get a unique inode number
|
|
|
|
* @sb: superblock
|
|
|
|
* @max_reserved: highest reserved inode number
|
|
|
|
*
|
|
|
|
* Obtain an inode number that is unique on the system for a given
|
|
|
|
* superblock. This is used by file systems that have no natural
|
|
|
|
* permanent inode numbering system. An inode number is returned that
|
|
|
|
* is higher than the reserved limit but unique.
|
|
|
|
*
|
|
|
|
* BUGS:
|
|
|
|
* With a large number of inodes live on the file system this function
|
|
|
|
* currently becomes quite slow.
|
|
|
|
*/
|
|
|
|
ino_t iunique(struct super_block *sb, ino_t max_reserved)
|
|
|
|
{
|
inode numbering: make static counters in new_inode and iunique be 32 bits
The problems are:
- on filesystems w/o permanent inode numbers, i_ino values can be larger
than 32 bits, which can cause problems for some 32 bit userspace programs on
a 64 bit kernel. We can't do anything for filesystems that have actual
>32-bit inode numbers, but on filesystems that generate i_ino values on the
fly, we should try to have them fit in 32 bits. We could trivially fix this
by making the static counters in new_inode and iunique 32 bits, but...
- many filesystems call new_inode and assume that the i_ino values they are
given are unique. They are not guaranteed to be so, since the static
counter can wrap. This problem is exacerbated by the fix for #1.
- after allocating a new inode, some filesystems call iunique to try to get
a unique i_ino value, but they don't actually add their inodes to the
hashtable, and so they're still not guaranteed to be unique if that counter
wraps.
This patch set takes the simpler approach of simply using iunique and hashing
the inodes afterward. Christoph H. previously mentioned that he thought that
this approach may slow down lookups for filesystems that currently hash their
inodes.
The questions are:
1) how much would this slow down lookups for these filesystems?
2) is it enough to justify adding more infrastructure to avoid it?
What might be best is to start with this approach and then only move to using
IDR or some other scheme if these extra inodes in the hashtable prove to be
problematic.
I've done some cursory testing with this patch and the overhead of hashing and
unhashing the inodes with pipefs is pretty low -- just a few seconds of system
time added on to the creation and destruction of 10 million pipes (very
similar to the overhead that the IDR approach would add).
The hard thing to measure is what effect this has on other filesystems. I'm
open to ways to try and gauge this.
Again, I've only converted pipefs as an example. If this approach is
acceptable then I'll start work on patches to convert other filesystems.
With a pretty-much-worst-case microbenchmark provided by Eric Dumazet
<dada1@cosmosbay.com>:
hashing patch (pipebench):
sys 1m15.329s
sys 1m16.249s
sys 1m17.169s
unpatched (pipebench):
sys 1m9.836s
sys 1m12.541s
sys 1m14.153s
Which works out to 1.05642174294555027017. So ~5-6% slowdown.
This patch:
When a 32-bit program that was not compiled with large file offsets does a
stat and gets a st_ino value back that won't fit in the 32 bit field, glibc
(correctly) generates an EOVERFLOW error. We can't do anything about fs's
with larger permanent inode numbers, but when we generate them on the fly, we
ought to try and have them fit within a 32 bit field.
This patch takes the first step toward this by making the static counters in
these two functions be 32 bits.
[jlayton@redhat.com: mention that it's only the case for 32bit, non-LFS stat]
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-05-08 07:32:29 +00:00
|
|
|
/*
|
|
|
|
* On a 32bit, non LFS stat() call, glibc will generate an EOVERFLOW
|
|
|
|
* error if st_ino won't fit in target struct field. Use 32bit counter
|
|
|
|
* here to attempt to avoid that.
|
|
|
|
*/
|
2010-10-23 11:00:16 +00:00
|
|
|
static DEFINE_SPINLOCK(iunique_lock);
|
inode numbering: make static counters in new_inode and iunique be 32 bits
The problems are:
- on filesystems w/o permanent inode numbers, i_ino values can be larger
than 32 bits, which can cause problems for some 32 bit userspace programs on
a 64 bit kernel. We can't do anything for filesystems that have actual
>32-bit inode numbers, but on filesystems that generate i_ino values on the
fly, we should try to have them fit in 32 bits. We could trivially fix this
by making the static counters in new_inode and iunique 32 bits, but...
- many filesystems call new_inode and assume that the i_ino values they are
given are unique. They are not guaranteed to be so, since the static
counter can wrap. This problem is exacerbated by the fix for #1.
- after allocating a new inode, some filesystems call iunique to try to get
a unique i_ino value, but they don't actually add their inodes to the
hashtable, and so they're still not guaranteed to be unique if that counter
wraps.
This patch set takes the simpler approach of simply using iunique and hashing
the inodes afterward. Christoph H. previously mentioned that he thought that
this approach may slow down lookups for filesystems that currently hash their
inodes.
The questions are:
1) how much would this slow down lookups for these filesystems?
2) is it enough to justify adding more infrastructure to avoid it?
What might be best is to start with this approach and then only move to using
IDR or some other scheme if these extra inodes in the hashtable prove to be
problematic.
I've done some cursory testing with this patch and the overhead of hashing and
unhashing the inodes with pipefs is pretty low -- just a few seconds of system
time added on to the creation and destruction of 10 million pipes (very
similar to the overhead that the IDR approach would add).
The hard thing to measure is what effect this has on other filesystems. I'm
open to ways to try and gauge this.
Again, I've only converted pipefs as an example. If this approach is
acceptable then I'll start work on patches to convert other filesystems.
With a pretty-much-worst-case microbenchmark provided by Eric Dumazet
<dada1@cosmosbay.com>:
hashing patch (pipebench):
sys 1m15.329s
sys 1m16.249s
sys 1m17.169s
unpatched (pipebench):
sys 1m9.836s
sys 1m12.541s
sys 1m14.153s
Which works out to 1.05642174294555027017. So ~5-6% slowdown.
This patch:
When a 32-bit program that was not compiled with large file offsets does a
stat and gets a st_ino value back that won't fit in the 32 bit field, glibc
(correctly) generates an EOVERFLOW error. We can't do anything about fs's
with larger permanent inode numbers, but when we generate them on the fly, we
ought to try and have them fit within a 32 bit field.
This patch takes the first step toward this by making the static counters in
these two functions be 32 bits.
[jlayton@redhat.com: mention that it's only the case for 32bit, non-LFS stat]
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-05-08 07:32:29 +00:00
|
|
|
static unsigned int counter;
|
2005-04-16 22:20:36 +00:00
|
|
|
ino_t res;
|
2007-05-08 07:29:48 +00:00
|
|
|
|
2017-12-01 11:40:16 +00:00
|
|
|
rcu_read_lock();
|
2010-10-23 11:00:16 +00:00
|
|
|
spin_lock(&iunique_lock);
|
2007-05-08 07:29:48 +00:00
|
|
|
do {
|
|
|
|
if (counter <= max_reserved)
|
|
|
|
counter = max_reserved + 1;
|
2005-04-16 22:20:36 +00:00
|
|
|
res = counter++;
|
2010-10-23 11:00:16 +00:00
|
|
|
} while (!test_inode_iunique(sb, res));
|
|
|
|
spin_unlock(&iunique_lock);
|
2017-12-01 11:40:16 +00:00
|
|
|
rcu_read_unlock();
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2007-05-08 07:29:48 +00:00
|
|
|
return res;
|
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
EXPORT_SYMBOL(iunique);
|
|
|
|
|
|
|
|
struct inode *igrab(struct inode *inode)
|
|
|
|
{
|
2011-03-22 11:23:36 +00:00
|
|
|
spin_lock(&inode->i_lock);
|
|
|
|
if (!(inode->i_state & (I_FREEING|I_WILL_FREE))) {
|
2005-04-16 22:20:36 +00:00
|
|
|
__iget(inode);
|
2011-03-22 11:23:36 +00:00
|
|
|
spin_unlock(&inode->i_lock);
|
|
|
|
} else {
|
|
|
|
spin_unlock(&inode->i_lock);
|
2005-04-16 22:20:36 +00:00
|
|
|
/*
|
|
|
|
* Handle the case where s_op->clear_inode is not been
|
|
|
|
* called yet, and somebody is calling igrab
|
|
|
|
* while the inode is getting freed.
|
|
|
|
*/
|
|
|
|
inode = NULL;
|
2011-03-22 11:23:36 +00:00
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
return inode;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(igrab);
|
|
|
|
|
|
|
|
/**
|
2011-03-23 19:03:28 +00:00
|
|
|
* ilookup5_nowait - search for an inode in the inode cache
|
2005-04-16 22:20:36 +00:00
|
|
|
* @sb: super block of file system to search
|
2011-03-23 19:03:28 +00:00
|
|
|
* @hashval: hash value (usually inode number) to search for
|
2005-04-16 22:20:36 +00:00
|
|
|
* @test: callback used for comparisons between inodes
|
|
|
|
* @data: opaque data pointer to pass to @test
|
|
|
|
*
|
2011-03-23 19:03:28 +00:00
|
|
|
* Search for the inode specified by @hashval and @data in the inode cache.
|
2005-04-16 22:20:36 +00:00
|
|
|
* If the inode is in the cache, the inode is returned with an incremented
|
|
|
|
* reference count.
|
|
|
|
*
|
2011-03-23 19:03:28 +00:00
|
|
|
* Note: I_NEW is not waited upon so you have to be very careful what you do
|
|
|
|
* with the returned inode. You probably should be using ilookup5() instead.
|
2005-04-16 22:20:36 +00:00
|
|
|
*
|
2011-03-26 20:27:47 +00:00
|
|
|
* Note2: @test is called with the inode_hash_lock held, so can't sleep.
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
2011-03-23 19:03:28 +00:00
|
|
|
struct inode *ilookup5_nowait(struct super_block *sb, unsigned long hashval,
|
|
|
|
int (*test)(struct inode *, void *), void *data)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2011-03-23 19:03:28 +00:00
|
|
|
struct hlist_head *head = inode_hashtable + hash(sb, hashval);
|
2005-04-16 22:20:36 +00:00
|
|
|
struct inode *inode;
|
|
|
|
|
2011-03-22 11:23:42 +00:00
|
|
|
spin_lock(&inode_hash_lock);
|
vfs: add rcu-based find_inode variants for iget ops
This avoids one inode hash lock acquire in the common case on inode
creation, in effect significantly reducing contention.
On the stock kernel said lock is typically taken twice:
1. once to check if the inode happens to already be present
2. once to add it to the hash
The back-to-back lock/unlock pattern is known to degrade performance
significantly, which is further exacerbated if the hash is heavily
populated (long chains to walk, extending hold time). Arguably hash
sizing and hashing algo need to be revisited, but that's beyond the
scope of this patch.
With the acquire from step 1 eliminated with RCU lookup throughput
increases significantly at the scale of 20 cores (benchmark results at
the bottom).
So happens the hash already supports RCU-based operation, but lookups on
inode insertions didn't take advantage of it.
This of course has its limits as the global lock is still a bottleneck.
There was a patchset posted which introduced fine-grained locking[1] but
it appears staled. Apart from that doubt was expressed whether a
handrolled hash implementation is appropriate to begin with, suggesting
replacement with rhashtables. Nobody committed to carrying [1] across
the finish line or implementing anything better, thus the bandaid below.
iget_locked consumers (notably ext4) get away without any changes
because inode comparison method is built-in.
iget5_locked consumers pass a custom callback. Since removal of locking
adds more problems (inode can be changing) it's not safe to assume all
filesystems happen to cope. Thus iget5_locked_rcu gets added, requiring
manual conversion of interested filesystems.
In order to reduce code duplication find_inode and find_inode_fast grow
an argument indicating whether inode hash lock is held, which is passed
down in case sleeping is necessary. They always rcu_read_lock, which is
redundant but harmless. Doing it conditionally reduces readability for
no real gain that I can see. RCU-alike restrictions were already put on
callbacks due to the hash spinlock being held.
Benchmarking:
There is a real cache-busting workload scanning millions of files in
parallel (it's a backup appliance), where the initial lookup is
guaranteed to fail resulting in the two lock acquires on stock kernel
(and one with the patch at hand).
Implemented below is a synthetic benchmark providing the same behavior.
[I shall note the workload is not running on Linux, instead it was
causing trouble elsewhere. Benchmark below was used while addressing
said problems and was found to adequately represent the real workload.]
Total real time fluctuates by 1-2s.
With 20 threads each walking a dedicated 1000 dirs * 1000 files
directory tree to stat(2) on a 32 core + 24GB RAM vm:
ext4 (needed mkfs.ext4 -N 24000000):
before: 3.77s user 890.90s system 1939% cpu 46.118 total
after: 3.24s user 397.73s system 1858% cpu 21.581 total (-53%)
That's 20 million files to visit, while the machine can only cache about
15 million at a time (obtained from ext4_inode_cache object count in
/proc/slabinfo). Since each terminal inode is only visited once per run
this amounts to 0% hit ratio for the dentry cache and the hash table
(there are however hits for the intermediate directories).
On repeated runs the kernel caches the last ~15 mln, meaning there is ~5
mln of uncached inodes which are going to be visited first, evicting the
previously cached state as it happens.
Lack of hits can be trivially verified with bpftrace, like so:
bpftrace -e 'kretprobe:find_inode_fast { @[kstack(), retval != 0] = count(); }'\
-c "/bin/sh walktrees /testfs 20"
Best ran more than once.
Expected results after "warmup":
[snip]
@[
__ext4_iget+275
ext4_lookup+224
__lookup_slow+130
walk_component+219
link_path_walk.part.0.constprop.0+614
path_lookupat+62
filename_lookup+204
vfs_statx+128
vfs_fstatat+131
__do_sys_newfstatat+38
do_syscall_64+87
entry_SYSCALL_64_after_hwframe+118
, 1]: 20000
@[
__ext4_iget+275
ext4_lookup+224
__lookup_slow+130
walk_component+219
path_lookupat+106
filename_lookup+204
vfs_statx+128
vfs_fstatat+131
__do_sys_newfstatat+38
do_syscall_64+87
entry_SYSCALL_64_after_hwframe+118
, 1]: 20000000
That is 20 million calls for the initial lookup and 20 million after
allocating a new inode, all of them failing to return a value != 0
(i.e., they are returning NULL -- no match found).
Of course aborting the benchmark in the middle and starting it again (or
messing with the state in other ways) is going to alter these results.
Benchmark can be found here: https://people.freebsd.org/~mjg/fstree.tgz
[1] https://lore.kernel.org/all/20231206060629.2827226-1-david@fromorbit.com/
Signed-off-by: Mateusz Guzik <mjguzik@gmail.com>
Link: https://lore.kernel.org/r/20240611173824.535995-2-mjguzik@gmail.com
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-06-11 17:38:22 +00:00
|
|
|
inode = find_inode(sb, head, test, data, true);
|
2011-03-22 11:23:42 +00:00
|
|
|
spin_unlock(&inode_hash_lock);
|
2005-07-13 08:10:44 +00:00
|
|
|
|
2018-06-28 19:53:17 +00:00
|
|
|
return IS_ERR(inode) ? NULL : inode;
|
2005-07-13 08:10:44 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(ilookup5_nowait);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ilookup5 - search for an inode in the inode cache
|
|
|
|
* @sb: super block of file system to search
|
|
|
|
* @hashval: hash value (usually inode number) to search for
|
|
|
|
* @test: callback used for comparisons between inodes
|
|
|
|
* @data: opaque data pointer to pass to @test
|
|
|
|
*
|
2011-03-23 19:03:28 +00:00
|
|
|
* Search for the inode specified by @hashval and @data in the inode cache,
|
|
|
|
* and if the inode is in the cache, return the inode with an incremented
|
|
|
|
* reference count. Waits on I_NEW before returning the inode.
|
2005-07-13 08:10:44 +00:00
|
|
|
* returned with an incremented reference count.
|
2005-04-16 22:20:36 +00:00
|
|
|
*
|
2011-03-23 19:03:28 +00:00
|
|
|
* This is a generalized version of ilookup() for file systems where the
|
|
|
|
* inode number is not sufficient for unique identification of an inode.
|
2005-04-16 22:20:36 +00:00
|
|
|
*
|
2011-03-23 19:03:28 +00:00
|
|
|
* Note: @test is called with the inode_hash_lock held, so can't sleep.
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
|
|
|
struct inode *ilookup5(struct super_block *sb, unsigned long hashval,
|
|
|
|
int (*test)(struct inode *, void *), void *data)
|
|
|
|
{
|
2016-07-04 03:15:21 +00:00
|
|
|
struct inode *inode;
|
|
|
|
again:
|
|
|
|
inode = ilookup5_nowait(sb, hashval, test, data);
|
|
|
|
if (inode) {
|
2011-03-23 19:03:28 +00:00
|
|
|
wait_on_inode(inode);
|
2016-07-04 03:15:21 +00:00
|
|
|
if (unlikely(inode_unhashed(inode))) {
|
|
|
|
iput(inode);
|
|
|
|
goto again;
|
|
|
|
}
|
|
|
|
}
|
2011-03-23 19:03:28 +00:00
|
|
|
return inode;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(ilookup5);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ilookup - search for an inode in the inode cache
|
|
|
|
* @sb: super block of file system to search
|
|
|
|
* @ino: inode number to search for
|
|
|
|
*
|
2011-03-23 19:03:28 +00:00
|
|
|
* Search for the inode @ino in the inode cache, and if the inode is in the
|
|
|
|
* cache, the inode is returned with an incremented reference count.
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
|
|
|
struct inode *ilookup(struct super_block *sb, unsigned long ino)
|
|
|
|
{
|
|
|
|
struct hlist_head *head = inode_hashtable + hash(sb, ino);
|
|
|
|
struct inode *inode;
|
2016-07-04 03:15:21 +00:00
|
|
|
again:
|
2024-07-15 07:13:24 +00:00
|
|
|
inode = find_inode_fast(sb, head, ino, false);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2016-07-04 03:15:21 +00:00
|
|
|
if (inode) {
|
2018-06-28 19:53:17 +00:00
|
|
|
if (IS_ERR(inode))
|
|
|
|
return NULL;
|
2011-03-23 19:03:28 +00:00
|
|
|
wait_on_inode(inode);
|
2016-07-04 03:15:21 +00:00
|
|
|
if (unlikely(inode_unhashed(inode))) {
|
|
|
|
iput(inode);
|
|
|
|
goto again;
|
|
|
|
}
|
|
|
|
}
|
2011-03-23 19:03:28 +00:00
|
|
|
return inode;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
2011-03-23 19:03:28 +00:00
|
|
|
EXPORT_SYMBOL(ilookup);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2015-02-02 05:37:01 +00:00
|
|
|
/**
|
|
|
|
* find_inode_nowait - find an inode in the inode cache
|
|
|
|
* @sb: super block of file system to search
|
|
|
|
* @hashval: hash value (usually inode number) to search for
|
|
|
|
* @match: callback used for comparisons between inodes
|
|
|
|
* @data: opaque data pointer to pass to @match
|
|
|
|
*
|
|
|
|
* Search for the inode specified by @hashval and @data in the inode
|
|
|
|
* cache, where the helper function @match will return 0 if the inode
|
|
|
|
* does not match, 1 if the inode does match, and -1 if the search
|
|
|
|
* should be stopped. The @match function must be responsible for
|
|
|
|
* taking the i_lock spin_lock and checking i_state for an inode being
|
|
|
|
* freed or being initialized, and incrementing the reference count
|
|
|
|
* before returning 1. It also must not sleep, since it is called with
|
|
|
|
* the inode_hash_lock spinlock held.
|
|
|
|
*
|
|
|
|
* This is a even more generalized version of ilookup5() when the
|
|
|
|
* function must never block --- find_inode() can block in
|
|
|
|
* __wait_on_freeing_inode() --- or when the caller can not increment
|
|
|
|
* the reference count because the resulting iput() might cause an
|
|
|
|
* inode eviction. The tradeoff is that the @match funtion must be
|
|
|
|
* very carefully implemented.
|
|
|
|
*/
|
|
|
|
struct inode *find_inode_nowait(struct super_block *sb,
|
|
|
|
unsigned long hashval,
|
|
|
|
int (*match)(struct inode *, unsigned long,
|
|
|
|
void *),
|
|
|
|
void *data)
|
|
|
|
{
|
|
|
|
struct hlist_head *head = inode_hashtable + hash(sb, hashval);
|
|
|
|
struct inode *inode, *ret_inode = NULL;
|
|
|
|
int mval;
|
|
|
|
|
|
|
|
spin_lock(&inode_hash_lock);
|
|
|
|
hlist_for_each_entry(inode, head, i_hash) {
|
|
|
|
if (inode->i_sb != sb)
|
|
|
|
continue;
|
|
|
|
mval = match(inode, hashval, data);
|
|
|
|
if (mval == 0)
|
|
|
|
continue;
|
|
|
|
if (mval == 1)
|
|
|
|
ret_inode = inode;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
out:
|
|
|
|
spin_unlock(&inode_hash_lock);
|
|
|
|
return ret_inode;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(find_inode_nowait);
|
|
|
|
|
2017-12-01 11:40:16 +00:00
|
|
|
/**
|
|
|
|
* find_inode_rcu - find an inode in the inode cache
|
|
|
|
* @sb: Super block of file system to search
|
|
|
|
* @hashval: Key to hash
|
|
|
|
* @test: Function to test match on an inode
|
|
|
|
* @data: Data for test function
|
|
|
|
*
|
|
|
|
* Search for the inode specified by @hashval and @data in the inode cache,
|
|
|
|
* where the helper function @test will return 0 if the inode does not match
|
|
|
|
* and 1 if it does. The @test function must be responsible for taking the
|
|
|
|
* i_lock spin_lock and checking i_state for an inode being freed or being
|
|
|
|
* initialized.
|
|
|
|
*
|
|
|
|
* If successful, this will return the inode for which the @test function
|
|
|
|
* returned 1 and NULL otherwise.
|
|
|
|
*
|
|
|
|
* The @test function is not permitted to take a ref on any inode presented.
|
|
|
|
* It is also not permitted to sleep.
|
|
|
|
*
|
|
|
|
* The caller must hold the RCU read lock.
|
|
|
|
*/
|
|
|
|
struct inode *find_inode_rcu(struct super_block *sb, unsigned long hashval,
|
|
|
|
int (*test)(struct inode *, void *), void *data)
|
|
|
|
{
|
|
|
|
struct hlist_head *head = inode_hashtable + hash(sb, hashval);
|
|
|
|
struct inode *inode;
|
|
|
|
|
|
|
|
RCU_LOCKDEP_WARN(!rcu_read_lock_held(),
|
|
|
|
"suspicious find_inode_rcu() usage");
|
|
|
|
|
|
|
|
hlist_for_each_entry_rcu(inode, head, i_hash) {
|
|
|
|
if (inode->i_sb == sb &&
|
|
|
|
!(READ_ONCE(inode->i_state) & (I_FREEING | I_WILL_FREE)) &&
|
|
|
|
test(inode, data))
|
|
|
|
return inode;
|
|
|
|
}
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(find_inode_rcu);
|
|
|
|
|
|
|
|
/**
|
2021-01-14 08:04:39 +00:00
|
|
|
* find_inode_by_ino_rcu - Find an inode in the inode cache
|
2017-12-01 11:40:16 +00:00
|
|
|
* @sb: Super block of file system to search
|
|
|
|
* @ino: The inode number to match
|
|
|
|
*
|
|
|
|
* Search for the inode specified by @hashval and @data in the inode cache,
|
|
|
|
* where the helper function @test will return 0 if the inode does not match
|
|
|
|
* and 1 if it does. The @test function must be responsible for taking the
|
|
|
|
* i_lock spin_lock and checking i_state for an inode being freed or being
|
|
|
|
* initialized.
|
|
|
|
*
|
|
|
|
* If successful, this will return the inode for which the @test function
|
|
|
|
* returned 1 and NULL otherwise.
|
|
|
|
*
|
|
|
|
* The @test function is not permitted to take a ref on any inode presented.
|
|
|
|
* It is also not permitted to sleep.
|
|
|
|
*
|
|
|
|
* The caller must hold the RCU read lock.
|
|
|
|
*/
|
|
|
|
struct inode *find_inode_by_ino_rcu(struct super_block *sb,
|
|
|
|
unsigned long ino)
|
|
|
|
{
|
|
|
|
struct hlist_head *head = inode_hashtable + hash(sb, ino);
|
|
|
|
struct inode *inode;
|
|
|
|
|
|
|
|
RCU_LOCKDEP_WARN(!rcu_read_lock_held(),
|
|
|
|
"suspicious find_inode_by_ino_rcu() usage");
|
|
|
|
|
|
|
|
hlist_for_each_entry_rcu(inode, head, i_hash) {
|
|
|
|
if (inode->i_ino == ino &&
|
|
|
|
inode->i_sb == sb &&
|
|
|
|
!(READ_ONCE(inode->i_state) & (I_FREEING | I_WILL_FREE)))
|
|
|
|
return inode;
|
|
|
|
}
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(find_inode_by_ino_rcu);
|
|
|
|
|
2008-12-30 06:48:21 +00:00
|
|
|
int insert_inode_locked(struct inode *inode)
|
|
|
|
{
|
|
|
|
struct super_block *sb = inode->i_sb;
|
|
|
|
ino_t ino = inode->i_ino;
|
|
|
|
struct hlist_head *head = inode_hashtable + hash(sb, ino);
|
|
|
|
|
|
|
|
while (1) {
|
2009-05-13 18:13:40 +00:00
|
|
|
struct inode *old = NULL;
|
2011-03-22 11:23:42 +00:00
|
|
|
spin_lock(&inode_hash_lock);
|
hlist: drop the node parameter from iterators
I'm not sure why, but the hlist for each entry iterators were conceived
list_for_each_entry(pos, head, member)
The hlist ones were greedy and wanted an extra parameter:
hlist_for_each_entry(tpos, pos, head, member)
Why did they need an extra pos parameter? I'm not quite sure. Not only
they don't really need it, it also prevents the iterator from looking
exactly like the list iterator, which is unfortunate.
Besides the semantic patch, there was some manual work required:
- Fix up the actual hlist iterators in linux/list.h
- Fix up the declaration of other iterators based on the hlist ones.
- A very small amount of places were using the 'node' parameter, this
was modified to use 'obj->member' instead.
- Coccinelle didn't handle the hlist_for_each_entry_safe iterator
properly, so those had to be fixed up manually.
The semantic patch which is mostly the work of Peter Senna Tschudin is here:
@@
iterator name hlist_for_each_entry, hlist_for_each_entry_continue, hlist_for_each_entry_from, hlist_for_each_entry_rcu, hlist_for_each_entry_rcu_bh, hlist_for_each_entry_continue_rcu_bh, for_each_busy_worker, ax25_uid_for_each, ax25_for_each, inet_bind_bucket_for_each, sctp_for_each_hentry, sk_for_each, sk_for_each_rcu, sk_for_each_from, sk_for_each_safe, sk_for_each_bound, hlist_for_each_entry_safe, hlist_for_each_entry_continue_rcu, nr_neigh_for_each, nr_neigh_for_each_safe, nr_node_for_each, nr_node_for_each_safe, for_each_gfn_indirect_valid_sp, for_each_gfn_sp, for_each_host;
type T;
expression a,c,d,e;
identifier b;
statement S;
@@
-T b;
<+... when != b
(
hlist_for_each_entry(a,
- b,
c, d) S
|
hlist_for_each_entry_continue(a,
- b,
c) S
|
hlist_for_each_entry_from(a,
- b,
c) S
|
hlist_for_each_entry_rcu(a,
- b,
c, d) S
|
hlist_for_each_entry_rcu_bh(a,
- b,
c, d) S
|
hlist_for_each_entry_continue_rcu_bh(a,
- b,
c) S
|
for_each_busy_worker(a, c,
- b,
d) S
|
ax25_uid_for_each(a,
- b,
c) S
|
ax25_for_each(a,
- b,
c) S
|
inet_bind_bucket_for_each(a,
- b,
c) S
|
sctp_for_each_hentry(a,
- b,
c) S
|
sk_for_each(a,
- b,
c) S
|
sk_for_each_rcu(a,
- b,
c) S
|
sk_for_each_from
-(a, b)
+(a)
S
+ sk_for_each_from(a) S
|
sk_for_each_safe(a,
- b,
c, d) S
|
sk_for_each_bound(a,
- b,
c) S
|
hlist_for_each_entry_safe(a,
- b,
c, d, e) S
|
hlist_for_each_entry_continue_rcu(a,
- b,
c) S
|
nr_neigh_for_each(a,
- b,
c) S
|
nr_neigh_for_each_safe(a,
- b,
c, d) S
|
nr_node_for_each(a,
- b,
c) S
|
nr_node_for_each_safe(a,
- b,
c, d) S
|
- for_each_gfn_sp(a, c, d, b) S
+ for_each_gfn_sp(a, c, d) S
|
- for_each_gfn_indirect_valid_sp(a, c, d, b) S
+ for_each_gfn_indirect_valid_sp(a, c, d) S
|
for_each_host(a,
- b,
c) S
|
for_each_host_safe(a,
- b,
c, d) S
|
for_each_mesh_entry(a,
- b,
c, d) S
)
...+>
[akpm@linux-foundation.org: drop bogus change from net/ipv4/raw.c]
[akpm@linux-foundation.org: drop bogus hunk from net/ipv6/raw.c]
[akpm@linux-foundation.org: checkpatch fixes]
[akpm@linux-foundation.org: fix warnings]
[akpm@linux-foudnation.org: redo intrusive kvm changes]
Tested-by: Peter Senna Tschudin <peter.senna@gmail.com>
Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Cc: Wu Fengguang <fengguang.wu@intel.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Gleb Natapov <gleb@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-02-28 01:06:00 +00:00
|
|
|
hlist_for_each_entry(old, head, i_hash) {
|
2009-05-13 18:13:40 +00:00
|
|
|
if (old->i_ino != ino)
|
|
|
|
continue;
|
|
|
|
if (old->i_sb != sb)
|
|
|
|
continue;
|
2011-03-22 11:23:36 +00:00
|
|
|
spin_lock(&old->i_lock);
|
|
|
|
if (old->i_state & (I_FREEING|I_WILL_FREE)) {
|
|
|
|
spin_unlock(&old->i_lock);
|
2009-05-13 18:13:40 +00:00
|
|
|
continue;
|
2011-03-22 11:23:36 +00:00
|
|
|
}
|
2009-05-13 18:13:40 +00:00
|
|
|
break;
|
|
|
|
}
|
hlist: drop the node parameter from iterators
I'm not sure why, but the hlist for each entry iterators were conceived
list_for_each_entry(pos, head, member)
The hlist ones were greedy and wanted an extra parameter:
hlist_for_each_entry(tpos, pos, head, member)
Why did they need an extra pos parameter? I'm not quite sure. Not only
they don't really need it, it also prevents the iterator from looking
exactly like the list iterator, which is unfortunate.
Besides the semantic patch, there was some manual work required:
- Fix up the actual hlist iterators in linux/list.h
- Fix up the declaration of other iterators based on the hlist ones.
- A very small amount of places were using the 'node' parameter, this
was modified to use 'obj->member' instead.
- Coccinelle didn't handle the hlist_for_each_entry_safe iterator
properly, so those had to be fixed up manually.
The semantic patch which is mostly the work of Peter Senna Tschudin is here:
@@
iterator name hlist_for_each_entry, hlist_for_each_entry_continue, hlist_for_each_entry_from, hlist_for_each_entry_rcu, hlist_for_each_entry_rcu_bh, hlist_for_each_entry_continue_rcu_bh, for_each_busy_worker, ax25_uid_for_each, ax25_for_each, inet_bind_bucket_for_each, sctp_for_each_hentry, sk_for_each, sk_for_each_rcu, sk_for_each_from, sk_for_each_safe, sk_for_each_bound, hlist_for_each_entry_safe, hlist_for_each_entry_continue_rcu, nr_neigh_for_each, nr_neigh_for_each_safe, nr_node_for_each, nr_node_for_each_safe, for_each_gfn_indirect_valid_sp, for_each_gfn_sp, for_each_host;
type T;
expression a,c,d,e;
identifier b;
statement S;
@@
-T b;
<+... when != b
(
hlist_for_each_entry(a,
- b,
c, d) S
|
hlist_for_each_entry_continue(a,
- b,
c) S
|
hlist_for_each_entry_from(a,
- b,
c) S
|
hlist_for_each_entry_rcu(a,
- b,
c, d) S
|
hlist_for_each_entry_rcu_bh(a,
- b,
c, d) S
|
hlist_for_each_entry_continue_rcu_bh(a,
- b,
c) S
|
for_each_busy_worker(a, c,
- b,
d) S
|
ax25_uid_for_each(a,
- b,
c) S
|
ax25_for_each(a,
- b,
c) S
|
inet_bind_bucket_for_each(a,
- b,
c) S
|
sctp_for_each_hentry(a,
- b,
c) S
|
sk_for_each(a,
- b,
c) S
|
sk_for_each_rcu(a,
- b,
c) S
|
sk_for_each_from
-(a, b)
+(a)
S
+ sk_for_each_from(a) S
|
sk_for_each_safe(a,
- b,
c, d) S
|
sk_for_each_bound(a,
- b,
c) S
|
hlist_for_each_entry_safe(a,
- b,
c, d, e) S
|
hlist_for_each_entry_continue_rcu(a,
- b,
c) S
|
nr_neigh_for_each(a,
- b,
c) S
|
nr_neigh_for_each_safe(a,
- b,
c, d) S
|
nr_node_for_each(a,
- b,
c) S
|
nr_node_for_each_safe(a,
- b,
c, d) S
|
- for_each_gfn_sp(a, c, d, b) S
+ for_each_gfn_sp(a, c, d) S
|
- for_each_gfn_indirect_valid_sp(a, c, d, b) S
+ for_each_gfn_indirect_valid_sp(a, c, d) S
|
for_each_host(a,
- b,
c) S
|
for_each_host_safe(a,
- b,
c, d) S
|
for_each_mesh_entry(a,
- b,
c, d) S
)
...+>
[akpm@linux-foundation.org: drop bogus change from net/ipv4/raw.c]
[akpm@linux-foundation.org: drop bogus hunk from net/ipv6/raw.c]
[akpm@linux-foundation.org: checkpatch fixes]
[akpm@linux-foundation.org: fix warnings]
[akpm@linux-foudnation.org: redo intrusive kvm changes]
Tested-by: Peter Senna Tschudin <peter.senna@gmail.com>
Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Cc: Wu Fengguang <fengguang.wu@intel.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Gleb Natapov <gleb@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-02-28 01:06:00 +00:00
|
|
|
if (likely(!old)) {
|
2011-03-22 11:23:36 +00:00
|
|
|
spin_lock(&inode->i_lock);
|
2018-06-28 19:53:17 +00:00
|
|
|
inode->i_state |= I_NEW | I_CREATING;
|
2017-12-01 11:40:16 +00:00
|
|
|
hlist_add_head_rcu(&inode->i_hash, head);
|
2011-03-22 11:23:36 +00:00
|
|
|
spin_unlock(&inode->i_lock);
|
2011-03-22 11:23:42 +00:00
|
|
|
spin_unlock(&inode_hash_lock);
|
2008-12-30 06:48:21 +00:00
|
|
|
return 0;
|
|
|
|
}
|
2018-06-28 19:53:17 +00:00
|
|
|
if (unlikely(old->i_state & I_CREATING)) {
|
|
|
|
spin_unlock(&old->i_lock);
|
|
|
|
spin_unlock(&inode_hash_lock);
|
|
|
|
return -EBUSY;
|
|
|
|
}
|
2008-12-30 06:48:21 +00:00
|
|
|
__iget(old);
|
2011-03-22 11:23:36 +00:00
|
|
|
spin_unlock(&old->i_lock);
|
2011-03-22 11:23:42 +00:00
|
|
|
spin_unlock(&inode_hash_lock);
|
2008-12-30 06:48:21 +00:00
|
|
|
wait_on_inode(old);
|
2010-10-23 19:19:20 +00:00
|
|
|
if (unlikely(!inode_unhashed(old))) {
|
2008-12-30 06:48:21 +00:00
|
|
|
iput(old);
|
|
|
|
return -EBUSY;
|
|
|
|
}
|
|
|
|
iput(old);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(insert_inode_locked);
|
|
|
|
|
|
|
|
int insert_inode_locked4(struct inode *inode, unsigned long hashval,
|
|
|
|
int (*test)(struct inode *, void *), void *data)
|
|
|
|
{
|
2018-06-28 19:53:17 +00:00
|
|
|
struct inode *old;
|
|
|
|
|
|
|
|
inode->i_state |= I_CREATING;
|
|
|
|
old = inode_insert5(inode, hashval, test, NULL, data);
|
2008-12-30 06:48:21 +00:00
|
|
|
|
2018-05-17 08:53:05 +00:00
|
|
|
if (old != inode) {
|
2008-12-30 06:48:21 +00:00
|
|
|
iput(old);
|
2018-05-17 08:53:05 +00:00
|
|
|
return -EBUSY;
|
2008-12-30 06:48:21 +00:00
|
|
|
}
|
2018-05-17 08:53:05 +00:00
|
|
|
return 0;
|
2008-12-30 06:48:21 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(insert_inode_locked4);
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2010-06-07 17:43:19 +00:00
|
|
|
int generic_delete_inode(struct inode *inode)
|
|
|
|
{
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(generic_delete_inode);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Called when we're dropping the last reference
|
|
|
|
* to an inode.
|
2009-09-18 20:05:44 +00:00
|
|
|
*
|
2010-06-07 17:43:19 +00:00
|
|
|
* Call the FS "drop_inode()" function, defaulting to
|
|
|
|
* the legacy UNIX filesystem behaviour. If it tells
|
|
|
|
* us to evict inode, do so. Otherwise, retain inode
|
|
|
|
* in cache if fs is alive, sync and evict if fs is
|
|
|
|
* shutting down.
|
2009-09-18 20:05:44 +00:00
|
|
|
*/
|
2010-06-07 17:43:19 +00:00
|
|
|
static void iput_final(struct inode *inode)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
|
|
|
struct super_block *sb = inode->i_sb;
|
2010-06-07 17:43:19 +00:00
|
|
|
const struct super_operations *op = inode->i_sb->s_op;
|
2017-12-01 11:40:16 +00:00
|
|
|
unsigned long state;
|
2010-06-07 17:43:19 +00:00
|
|
|
int drop;
|
|
|
|
|
2011-03-22 11:23:36 +00:00
|
|
|
WARN_ON(inode->i_state & I_NEW);
|
|
|
|
|
2011-07-07 19:45:59 +00:00
|
|
|
if (op->drop_inode)
|
2010-06-07 17:43:19 +00:00
|
|
|
drop = op->drop_inode(inode);
|
|
|
|
else
|
|
|
|
drop = generic_drop_inode(inode);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2020-12-08 02:08:43 +00:00
|
|
|
if (!drop &&
|
|
|
|
!(inode->i_state & I_DONTCACHE) &&
|
|
|
|
(sb->s_flags & SB_ACTIVE)) {
|
vfs: keep inodes with page cache off the inode shrinker LRU
Historically (pre-2.5), the inode shrinker used to reclaim only empty
inodes and skip over those that still contained page cache. This caused
problems on highmem hosts: struct inode could put fill lowmem zones
before the cache was getting reclaimed in the highmem zones.
To address this, the inode shrinker started to strip page cache to
facilitate reclaiming lowmem. However, this comes with its own set of
problems: the shrinkers may drop actively used page cache just because
the inodes are not currently open or dirty - think working with a large
git tree. It further doesn't respect cgroup memory protection settings
and can cause priority inversions between containers.
Nowadays, the page cache also holds non-resident info for evicted cache
pages in order to detect refaults. We've come to rely heavily on this
data inside reclaim for protecting the cache workingset and driving swap
behavior. We also use it to quantify and report workload health through
psi. The latter in turn is used for fleet health monitoring, as well as
driving automated memory sizing of workloads and containers, proactive
reclaim and memory offloading schemes.
The consequences of dropping page cache prematurely is that we're seeing
subtle and not-so-subtle failures in all of the above-mentioned
scenarios, with the workload generally entering unexpected thrashing
states while losing the ability to reliably detect it.
To fix this on non-highmem systems at least, going back to rotating
inodes on the LRU isn't feasible. We've tried (commit a76cf1a474d7
("mm: don't reclaim inodes with many attached pages")) and failed
(commit 69056ee6a8a3 ("Revert "mm: don't reclaim inodes with many
attached pages"")).
The issue is mostly that shrinker pools attract pressure based on their
size, and when objects get skipped the shrinkers remember this as
deferred reclaim work. This accumulates excessive pressure on the
remaining inodes, and we can quickly eat into heavily used ones, or
dirty ones that require IO to reclaim, when there potentially is plenty
of cold, clean cache around still.
Instead, this patch keeps populated inodes off the inode LRU in the
first place - just like an open file or dirty state would. An otherwise
clean and unused inode then gets queued when the last cache entry
disappears. This solves the problem without reintroducing the reclaim
issues, and generally is a bit more scalable than having to wade through
potentially hundreds of thousands of busy inodes.
Locking is a bit tricky because the locks protecting the inode state
(i_lock) and the inode LRU (lru_list.lock) don't nest inside the
irq-safe page cache lock (i_pages.xa_lock). Page cache deletions are
serialized through i_lock, taken before the i_pages lock, to make sure
depopulated inodes are queued reliably. Additions may race with
deletions, but we'll check again in the shrinker. If additions race
with the shrinker itself, we're protected by the i_lock: if find_inode()
or iput() win, the shrinker will bail on the elevated i_count or
I_REFERENCED; if the shrinker wins and goes ahead with the inode, it
will set I_FREEING and inhibit further igets(), which will cause the
other side to create a new instance of the inode instead.
Link: https://lkml.kernel.org/r/20210614211904.14420-4-hannes@cmpxchg.org
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: Roman Gushchin <guro@fb.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: Dave Chinner <david@fromorbit.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-11-09 02:31:24 +00:00
|
|
|
__inode_add_lru(inode, true);
|
2011-03-22 11:23:37 +00:00
|
|
|
spin_unlock(&inode->i_lock);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2017-12-01 11:40:16 +00:00
|
|
|
state = inode->i_state;
|
2010-06-07 17:43:19 +00:00
|
|
|
if (!drop) {
|
2017-12-01 11:40:16 +00:00
|
|
|
WRITE_ONCE(inode->i_state, state | I_WILL_FREE);
|
2011-03-22 11:23:36 +00:00
|
|
|
spin_unlock(&inode->i_lock);
|
2017-12-01 11:40:16 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
write_inode_now(inode, 1);
|
2017-12-01 11:40:16 +00:00
|
|
|
|
2011-03-22 11:23:36 +00:00
|
|
|
spin_lock(&inode->i_lock);
|
2017-12-01 11:40:16 +00:00
|
|
|
state = inode->i_state;
|
|
|
|
WARN_ON(state & I_NEW);
|
|
|
|
state &= ~I_WILL_FREE;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
2010-10-21 00:49:30 +00:00
|
|
|
|
2017-12-01 11:40:16 +00:00
|
|
|
WRITE_ONCE(inode->i_state, state | I_FREEING);
|
2011-07-28 04:55:13 +00:00
|
|
|
if (!list_empty(&inode->i_lru))
|
|
|
|
inode_lru_list_del(inode);
|
2011-03-22 11:23:37 +00:00
|
|
|
spin_unlock(&inode->i_lock);
|
|
|
|
|
2010-06-07 17:21:05 +00:00
|
|
|
evict(inode);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2009-03-31 14:05:54 +00:00
|
|
|
* iput - put an inode
|
2005-04-16 22:20:36 +00:00
|
|
|
* @inode: inode to put
|
|
|
|
*
|
|
|
|
* Puts an inode, dropping its usage count. If the inode use count hits
|
|
|
|
* zero, the inode is then freed and may also be destroyed.
|
|
|
|
*
|
|
|
|
* Consequently, iput() can sleep.
|
|
|
|
*/
|
|
|
|
void iput(struct inode *inode)
|
|
|
|
{
|
2015-02-02 05:37:00 +00:00
|
|
|
if (!inode)
|
|
|
|
return;
|
|
|
|
BUG_ON(inode->i_state & I_CLEAR);
|
|
|
|
retry:
|
|
|
|
if (atomic_dec_and_lock(&inode->i_count, &inode->i_lock)) {
|
|
|
|
if (inode->i_nlink && (inode->i_state & I_DIRTY_TIME)) {
|
|
|
|
atomic_inc(&inode->i_count);
|
|
|
|
spin_unlock(&inode->i_lock);
|
|
|
|
trace_writeback_lazytime_iput(inode);
|
|
|
|
mark_inode_dirty_sync(inode);
|
|
|
|
goto retry;
|
|
|
|
}
|
|
|
|
iput_final(inode);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(iput);
|
|
|
|
|
2020-01-09 13:30:41 +00:00
|
|
|
#ifdef CONFIG_BLOCK
|
2005-04-16 22:20:36 +00:00
|
|
|
/**
|
|
|
|
* bmap - find a block number in a file
|
2020-01-09 13:30:41 +00:00
|
|
|
* @inode: inode owning the block number being requested
|
|
|
|
* @block: pointer containing the block to find
|
2005-04-16 22:20:36 +00:00
|
|
|
*
|
2020-04-14 16:48:57 +00:00
|
|
|
* Replaces the value in ``*block`` with the block number on the device holding
|
2020-01-09 13:30:41 +00:00
|
|
|
* corresponding to the requested block number in the file.
|
|
|
|
* That is, asked for block 4 of inode 1 the function will replace the
|
2020-04-14 16:48:57 +00:00
|
|
|
* 4 in ``*block``, with disk block relative to the disk start that holds that
|
2020-01-09 13:30:41 +00:00
|
|
|
* block of the file.
|
|
|
|
*
|
|
|
|
* Returns -EINVAL in case of error, 0 otherwise. If mapping falls into a
|
2020-04-14 16:48:57 +00:00
|
|
|
* hole, returns 0 and ``*block`` is also set to 0.
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
2020-01-09 13:30:41 +00:00
|
|
|
int bmap(struct inode *inode, sector_t *block)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2020-01-09 13:30:41 +00:00
|
|
|
if (!inode->i_mapping->a_ops->bmap)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
*block = inode->i_mapping->a_ops->bmap(inode->i_mapping, *block);
|
|
|
|
return 0;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(bmap);
|
2020-01-09 13:30:41 +00:00
|
|
|
#endif
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2009-03-26 17:32:14 +00:00
|
|
|
/*
|
|
|
|
* With relative atime, only update atime if the previous atime is
|
2023-03-25 08:22:32 +00:00
|
|
|
* earlier than or equal to either the ctime or mtime,
|
|
|
|
* or if at least a day has passed since the last atime update.
|
2009-03-26 17:32:14 +00:00
|
|
|
*/
|
2023-12-05 06:45:45 +00:00
|
|
|
static bool relatime_need_update(struct vfsmount *mnt, struct inode *inode,
|
2019-04-26 14:50:41 +00:00
|
|
|
struct timespec64 now)
|
2009-03-26 17:32:14 +00:00
|
|
|
{
|
2023-10-04 18:52:38 +00:00
|
|
|
struct timespec64 atime, mtime, ctime;
|
2009-03-26 17:32:14 +00:00
|
|
|
|
2018-07-18 13:44:43 +00:00
|
|
|
if (!(mnt->mnt_flags & MNT_RELATIME))
|
2023-12-05 06:45:45 +00:00
|
|
|
return true;
|
2009-03-26 17:32:14 +00:00
|
|
|
/*
|
2023-03-25 08:22:32 +00:00
|
|
|
* Is mtime younger than or equal to atime? If yes, update atime:
|
2009-03-26 17:32:14 +00:00
|
|
|
*/
|
2023-10-04 18:52:38 +00:00
|
|
|
atime = inode_get_atime(inode);
|
|
|
|
mtime = inode_get_mtime(inode);
|
|
|
|
if (timespec64_compare(&mtime, &atime) >= 0)
|
2023-12-05 06:45:45 +00:00
|
|
|
return true;
|
2009-03-26 17:32:14 +00:00
|
|
|
/*
|
2023-03-25 08:22:32 +00:00
|
|
|
* Is ctime younger than or equal to atime? If yes, update atime:
|
2009-03-26 17:32:14 +00:00
|
|
|
*/
|
2023-07-05 19:00:50 +00:00
|
|
|
ctime = inode_get_ctime(inode);
|
2023-10-04 18:52:38 +00:00
|
|
|
if (timespec64_compare(&ctime, &atime) >= 0)
|
2023-12-05 06:45:45 +00:00
|
|
|
return true;
|
2009-03-26 17:32:14 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Is the previous atime value older than a day? If yes,
|
|
|
|
* update atime:
|
|
|
|
*/
|
2023-10-04 18:52:38 +00:00
|
|
|
if ((long)(now.tv_sec - atime.tv_sec) >= 24*60*60)
|
2023-12-05 06:45:45 +00:00
|
|
|
return true;
|
2009-03-26 17:32:14 +00:00
|
|
|
/*
|
|
|
|
* Good, we can skip the atime update:
|
|
|
|
*/
|
2023-12-05 06:45:45 +00:00
|
|
|
return false;
|
2009-03-26 17:32:14 +00:00
|
|
|
}
|
|
|
|
|
2023-08-07 19:38:34 +00:00
|
|
|
/**
|
|
|
|
* inode_update_timestamps - update the timestamps on the inode
|
|
|
|
* @inode: inode to be updated
|
|
|
|
* @flags: S_* flags that needed to be updated
|
|
|
|
*
|
|
|
|
* The update_time function is called when an inode's timestamps need to be
|
|
|
|
* updated for a read or write operation. This function handles updating the
|
|
|
|
* actual timestamps. It's up to the caller to ensure that the inode is marked
|
|
|
|
* dirty appropriately.
|
|
|
|
*
|
|
|
|
* In the case where any of S_MTIME, S_CTIME, or S_VERSION need to be updated,
|
|
|
|
* attempt to update all three of them. S_ATIME updates can be handled
|
|
|
|
* independently of the rest.
|
|
|
|
*
|
|
|
|
* Returns a set of S_* flags indicating which values changed.
|
|
|
|
*/
|
|
|
|
int inode_update_timestamps(struct inode *inode, int flags)
|
2012-03-26 13:59:21 +00:00
|
|
|
{
|
2023-08-07 19:38:34 +00:00
|
|
|
int updated = 0;
|
|
|
|
struct timespec64 now;
|
2021-01-12 19:02:45 +00:00
|
|
|
|
2023-08-07 19:38:34 +00:00
|
|
|
if (flags & (S_MTIME|S_CTIME|S_VERSION)) {
|
|
|
|
struct timespec64 ctime = inode_get_ctime(inode);
|
2023-10-04 18:52:38 +00:00
|
|
|
struct timespec64 mtime = inode_get_mtime(inode);
|
2021-01-12 19:02:45 +00:00
|
|
|
|
2023-08-07 19:38:34 +00:00
|
|
|
now = inode_set_ctime_current(inode);
|
|
|
|
if (!timespec64_equal(&now, &ctime))
|
|
|
|
updated |= S_CTIME;
|
2023-10-04 18:52:38 +00:00
|
|
|
if (!timespec64_equal(&now, &mtime)) {
|
|
|
|
inode_set_mtime_to_ts(inode, now);
|
2023-08-07 19:38:34 +00:00
|
|
|
updated |= S_MTIME;
|
|
|
|
}
|
|
|
|
if (IS_I_VERSION(inode) && inode_maybe_inc_iversion(inode, updated))
|
|
|
|
updated |= S_VERSION;
|
|
|
|
} else {
|
|
|
|
now = current_time(inode);
|
2021-01-12 19:02:45 +00:00
|
|
|
}
|
|
|
|
|
2023-08-07 19:38:34 +00:00
|
|
|
if (flags & S_ATIME) {
|
2023-10-04 18:52:38 +00:00
|
|
|
struct timespec64 atime = inode_get_atime(inode);
|
|
|
|
|
|
|
|
if (!timespec64_equal(&now, &atime)) {
|
|
|
|
inode_set_atime_to_ts(inode, now);
|
2023-08-07 19:38:34 +00:00
|
|
|
updated |= S_ATIME;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return updated;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(inode_update_timestamps);
|
2021-01-12 19:02:45 +00:00
|
|
|
|
2023-08-07 19:38:34 +00:00
|
|
|
/**
|
|
|
|
* generic_update_time - update the timestamps on the inode
|
|
|
|
* @inode: inode to be updated
|
|
|
|
* @flags: S_* flags that needed to be updated
|
|
|
|
*
|
|
|
|
* The update_time function is called when an inode's timestamps need to be
|
|
|
|
* updated for a read or write operation. In the case where any of S_MTIME, S_CTIME,
|
|
|
|
* or S_VERSION need to be updated we attempt to update all three of them. S_ATIME
|
|
|
|
* updates can be handled done independently of the rest.
|
|
|
|
*
|
|
|
|
* Returns a S_* mask indicating which fields were updated.
|
|
|
|
*/
|
|
|
|
int generic_update_time(struct inode *inode, int flags)
|
|
|
|
{
|
|
|
|
int updated = inode_update_timestamps(inode, flags);
|
|
|
|
int dirty_flags = 0;
|
2021-01-12 19:02:45 +00:00
|
|
|
|
2023-08-07 19:38:34 +00:00
|
|
|
if (updated & (S_ATIME|S_MTIME|S_CTIME))
|
|
|
|
dirty_flags = inode->i_sb->s_flags & SB_LAZYTIME ? I_DIRTY_TIME : I_DIRTY_SYNC;
|
|
|
|
if (updated & S_VERSION)
|
|
|
|
dirty_flags |= I_DIRTY_SYNC;
|
2021-01-12 19:02:45 +00:00
|
|
|
__mark_inode_dirty(inode, dirty_flags);
|
2023-08-07 19:38:34 +00:00
|
|
|
return updated;
|
2012-03-26 13:59:21 +00:00
|
|
|
}
|
2015-02-02 05:37:00 +00:00
|
|
|
EXPORT_SYMBOL(generic_update_time);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This does the actual work of updating an inodes time or version. Must have
|
|
|
|
* had called mnt_want_write() before calling this.
|
|
|
|
*/
|
2023-08-07 19:38:39 +00:00
|
|
|
int inode_update_time(struct inode *inode, int flags)
|
2015-02-02 05:37:00 +00:00
|
|
|
{
|
2019-12-03 05:19:45 +00:00
|
|
|
if (inode->i_op->update_time)
|
2023-08-07 19:38:39 +00:00
|
|
|
return inode->i_op->update_time(inode, flags);
|
2023-08-07 19:38:34 +00:00
|
|
|
generic_update_time(inode, flags);
|
|
|
|
return 0;
|
2015-02-02 05:37:00 +00:00
|
|
|
}
|
2021-10-14 17:11:00 +00:00
|
|
|
EXPORT_SYMBOL(inode_update_time);
|
2012-03-26 13:59:21 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/**
|
2021-01-14 08:04:39 +00:00
|
|
|
* atime_needs_update - update the access time
|
2012-04-18 00:03:25 +00:00
|
|
|
* @path: the &struct path to update
|
2015-11-09 22:57:58 +00:00
|
|
|
* @inode: inode to update
|
2005-04-16 22:20:36 +00:00
|
|
|
*
|
|
|
|
* Update the accessed time on an inode and mark it for writeback.
|
|
|
|
* This function automatically handles read only file systems and media,
|
|
|
|
* as well as the "noatime" flag and inode specific "noatime" markers.
|
|
|
|
*/
|
2018-07-18 13:44:43 +00:00
|
|
|
bool atime_needs_update(const struct path *path, struct inode *inode)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2012-03-15 12:21:57 +00:00
|
|
|
struct vfsmount *mnt = path->mnt;
|
2023-10-04 18:52:38 +00:00
|
|
|
struct timespec64 now, atime;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2008-02-15 22:37:41 +00:00
|
|
|
if (inode->i_flags & S_NOATIME)
|
2015-03-23 02:37:40 +00:00
|
|
|
return false;
|
2016-06-29 19:54:46 +00:00
|
|
|
|
|
|
|
/* Atime updates will likely cause i_uid and i_gid to be written
|
|
|
|
* back improprely if their true value is unknown to the vfs.
|
|
|
|
*/
|
2023-01-13 11:49:22 +00:00
|
|
|
if (HAS_UNMAPPED_ID(mnt_idmap(mnt), inode))
|
2016-06-29 19:54:46 +00:00
|
|
|
return false;
|
|
|
|
|
2007-02-10 09:44:49 +00:00
|
|
|
if (IS_NOATIME(inode))
|
2015-03-23 02:37:40 +00:00
|
|
|
return false;
|
2017-11-27 21:05:09 +00:00
|
|
|
if ((inode->i_sb->s_flags & SB_NODIRATIME) && S_ISDIR(inode->i_mode))
|
2015-03-23 02:37:40 +00:00
|
|
|
return false;
|
2006-12-13 08:34:34 +00:00
|
|
|
|
2008-02-15 22:37:41 +00:00
|
|
|
if (mnt->mnt_flags & MNT_NOATIME)
|
2015-03-23 02:37:40 +00:00
|
|
|
return false;
|
2008-02-15 22:37:41 +00:00
|
|
|
if ((mnt->mnt_flags & MNT_NODIRATIME) && S_ISDIR(inode->i_mode))
|
2015-03-23 02:37:40 +00:00
|
|
|
return false;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2016-09-14 14:48:06 +00:00
|
|
|
now = current_time(inode);
|
2009-03-26 17:32:14 +00:00
|
|
|
|
2019-04-26 14:50:41 +00:00
|
|
|
if (!relatime_need_update(mnt, inode, now))
|
2015-03-23 02:37:40 +00:00
|
|
|
return false;
|
2009-03-26 17:32:14 +00:00
|
|
|
|
2023-10-04 18:52:38 +00:00
|
|
|
atime = inode_get_atime(inode);
|
|
|
|
if (timespec64_equal(&atime, &now))
|
2015-03-23 02:37:40 +00:00
|
|
|
return false;
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
void touch_atime(const struct path *path)
|
|
|
|
{
|
|
|
|
struct vfsmount *mnt = path->mnt;
|
|
|
|
struct inode *inode = d_inode(path->dentry);
|
|
|
|
|
2018-07-18 13:44:43 +00:00
|
|
|
if (!atime_needs_update(path, inode))
|
2009-09-18 20:05:47 +00:00
|
|
|
return;
|
|
|
|
|
2012-06-12 14:20:36 +00:00
|
|
|
if (!sb_start_write_trylock(inode->i_sb))
|
2009-09-18 20:05:47 +00:00
|
|
|
return;
|
2006-12-13 08:34:34 +00:00
|
|
|
|
2023-09-08 13:28:59 +00:00
|
|
|
if (mnt_get_write_access(mnt) != 0)
|
2012-06-12 14:20:36 +00:00
|
|
|
goto skip_update;
|
2012-03-26 13:59:21 +00:00
|
|
|
/*
|
|
|
|
* File systems can error out when updating inodes if they need to
|
|
|
|
* allocate new space to modify an inode (such is the case for
|
|
|
|
* Btrfs), but since we touch atime while walking down the path we
|
|
|
|
* really don't care if we failed to update the atime of the file,
|
|
|
|
* so just ignore the return value.
|
2012-06-15 07:49:33 +00:00
|
|
|
* We may also fail on filesystems that have the ability to make parts
|
|
|
|
* of the fs read only, e.g. subvolumes in Btrfs.
|
2012-03-26 13:59:21 +00:00
|
|
|
*/
|
2023-08-07 19:38:39 +00:00
|
|
|
inode_update_time(inode, S_ATIME);
|
2023-09-08 13:28:59 +00:00
|
|
|
mnt_put_write_access(mnt);
|
2012-06-12 14:20:36 +00:00
|
|
|
skip_update:
|
|
|
|
sb_end_write(inode->i_sb);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
2006-01-10 04:52:03 +00:00
|
|
|
EXPORT_SYMBOL(touch_atime);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2015-05-21 14:05:54 +00:00
|
|
|
/*
|
|
|
|
* Return mask of changes for notify_change() that need to be done as a
|
|
|
|
* response to write or truncate. Return 0 if nothing has to be changed.
|
|
|
|
* Negative value on error (change should be denied).
|
|
|
|
*/
|
2023-01-13 11:49:27 +00:00
|
|
|
int dentry_needs_remove_privs(struct mnt_idmap *idmap,
|
attr: use consistent sgid stripping checks
Currently setgid stripping in file_remove_privs()'s should_remove_suid()
helper is inconsistent with other parts of the vfs. Specifically, it only
raises ATTR_KILL_SGID if the inode is S_ISGID and S_IXGRP but not if the
inode isn't in the caller's groups and the caller isn't privileged over the
inode although we require this already in setattr_prepare() and
setattr_copy() and so all filesystem implement this requirement implicitly
because they have to use setattr_{prepare,copy}() anyway.
But the inconsistency shows up in setgid stripping bugs for overlayfs in
xfstests (e.g., generic/673, generic/683, generic/685, generic/686,
generic/687). For example, we test whether suid and setgid stripping works
correctly when performing various write-like operations as an unprivileged
user (fallocate, reflink, write, etc.):
echo "Test 1 - qa_user, non-exec file $verb"
setup_testfile
chmod a+rws $junk_file
commit_and_check "$qa_user" "$verb" 64k 64k
The test basically creates a file with 6666 permissions. While the file has
the S_ISUID and S_ISGID bits set it does not have the S_IXGRP set. On a
regular filesystem like xfs what will happen is:
sys_fallocate()
-> vfs_fallocate()
-> xfs_file_fallocate()
-> file_modified()
-> __file_remove_privs()
-> dentry_needs_remove_privs()
-> should_remove_suid()
-> __remove_privs()
newattrs.ia_valid = ATTR_FORCE | kill;
-> notify_change()
-> setattr_copy()
In should_remove_suid() we can see that ATTR_KILL_SUID is raised
unconditionally because the file in the test has S_ISUID set.
But we also see that ATTR_KILL_SGID won't be set because while the file
is S_ISGID it is not S_IXGRP (see above) which is a condition for
ATTR_KILL_SGID being raised.
So by the time we call notify_change() we have attr->ia_valid set to
ATTR_KILL_SUID | ATTR_FORCE. Now notify_change() sees that
ATTR_KILL_SUID is set and does:
ia_valid = attr->ia_valid |= ATTR_MODE
attr->ia_mode = (inode->i_mode & ~S_ISUID);
which means that when we call setattr_copy() later we will definitely
update inode->i_mode. Note that attr->ia_mode still contains S_ISGID.
Now we call into the filesystem's ->setattr() inode operation which will
end up calling setattr_copy(). Since ATTR_MODE is set we will hit:
if (ia_valid & ATTR_MODE) {
umode_t mode = attr->ia_mode;
vfsgid_t vfsgid = i_gid_into_vfsgid(mnt_userns, inode);
if (!vfsgid_in_group_p(vfsgid) &&
!capable_wrt_inode_uidgid(mnt_userns, inode, CAP_FSETID))
mode &= ~S_ISGID;
inode->i_mode = mode;
}
and since the caller in the test is neither capable nor in the group of the
inode the S_ISGID bit is stripped.
But assume the file isn't suid then ATTR_KILL_SUID won't be raised which
has the consequence that neither the setgid nor the suid bits are stripped
even though it should be stripped because the inode isn't in the caller's
groups and the caller isn't privileged over the inode.
If overlayfs is in the mix things become a bit more complicated and the bug
shows up more clearly. When e.g., ovl_setattr() is hit from
ovl_fallocate()'s call to file_remove_privs() then ATTR_KILL_SUID and
ATTR_KILL_SGID might be raised but because the check in notify_change() is
questioning the ATTR_KILL_SGID flag again by requiring S_IXGRP for it to be
stripped the S_ISGID bit isn't removed even though it should be stripped:
sys_fallocate()
-> vfs_fallocate()
-> ovl_fallocate()
-> file_remove_privs()
-> dentry_needs_remove_privs()
-> should_remove_suid()
-> __remove_privs()
newattrs.ia_valid = ATTR_FORCE | kill;
-> notify_change()
-> ovl_setattr()
// TAKE ON MOUNTER'S CREDS
-> ovl_do_notify_change()
-> notify_change()
// GIVE UP MOUNTER'S CREDS
// TAKE ON MOUNTER'S CREDS
-> vfs_fallocate()
-> xfs_file_fallocate()
-> file_modified()
-> __file_remove_privs()
-> dentry_needs_remove_privs()
-> should_remove_suid()
-> __remove_privs()
newattrs.ia_valid = attr_force | kill;
-> notify_change()
The fix for all of this is to make file_remove_privs()'s
should_remove_suid() helper to perform the same checks as we already
require in setattr_prepare() and setattr_copy() and have notify_change()
not pointlessly requiring S_IXGRP again. It doesn't make any sense in the
first place because the caller must calculate the flags via
should_remove_suid() anyway which would raise ATTR_KILL_SGID.
While we're at it we move should_remove_suid() from inode.c to attr.c
where it belongs with the rest of the iattr helpers. Especially since it
returns ATTR_KILL_S{G,U}ID flags. We also rename it to
setattr_should_drop_suidgid() to better reflect that it indicates both
setuid and setgid bit removal and also that it returns attr flags.
Running xfstests with this doesn't report any regressions. We should really
try and use consistent checks.
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Christian Brauner (Microsoft) <brauner@kernel.org>
2022-10-17 15:06:37 +00:00
|
|
|
struct dentry *dentry)
|
2015-05-21 14:05:54 +00:00
|
|
|
{
|
|
|
|
struct inode *inode = d_inode(dentry);
|
|
|
|
int mask = 0;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (IS_NOSEC(inode))
|
|
|
|
return 0;
|
|
|
|
|
2023-01-13 11:49:27 +00:00
|
|
|
mask = setattr_should_drop_suidgid(idmap, inode);
|
2015-05-21 14:05:54 +00:00
|
|
|
ret = security_inode_need_killpriv(dentry);
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
if (ret)
|
|
|
|
mask |= ATTR_KILL_PRIV;
|
|
|
|
return mask;
|
|
|
|
}
|
|
|
|
|
2023-01-13 11:49:10 +00:00
|
|
|
static int __remove_privs(struct mnt_idmap *idmap,
|
2021-01-21 13:19:34 +00:00
|
|
|
struct dentry *dentry, int kill)
|
2012-05-15 06:57:33 +00:00
|
|
|
{
|
|
|
|
struct iattr newattrs;
|
|
|
|
|
|
|
|
newattrs.ia_valid = ATTR_FORCE | kill;
|
2011-09-20 21:19:26 +00:00
|
|
|
/*
|
|
|
|
* Note we call this on write, so notify_change will not
|
|
|
|
* encounter any conflicting delegations:
|
|
|
|
*/
|
2023-01-13 11:49:10 +00:00
|
|
|
return notify_change(idmap, dentry, &newattrs, NULL);
|
2012-05-15 06:57:33 +00:00
|
|
|
}
|
|
|
|
|
2024-02-28 23:28:48 +00:00
|
|
|
int file_remove_privs_flags(struct file *file, unsigned int flags)
|
2012-05-15 06:57:33 +00:00
|
|
|
{
|
2016-08-03 11:44:27 +00:00
|
|
|
struct dentry *dentry = file_dentry(file);
|
|
|
|
struct inode *inode = file_inode(file);
|
2022-08-16 15:31:58 +00:00
|
|
|
int error = 0;
|
2015-05-21 14:05:54 +00:00
|
|
|
int kill;
|
2012-05-15 06:57:33 +00:00
|
|
|
|
2018-12-14 10:55:52 +00:00
|
|
|
if (IS_NOSEC(inode) || !S_ISREG(inode->i_mode))
|
2012-05-15 06:57:33 +00:00
|
|
|
return 0;
|
|
|
|
|
2023-01-13 11:49:27 +00:00
|
|
|
kill = dentry_needs_remove_privs(file_mnt_idmap(file), dentry);
|
2022-08-16 15:31:58 +00:00
|
|
|
if (kill < 0)
|
2015-05-21 14:05:54 +00:00
|
|
|
return kill;
|
2022-06-23 17:51:51 +00:00
|
|
|
|
2022-08-16 15:31:58 +00:00
|
|
|
if (kill) {
|
|
|
|
if (flags & IOCB_NOWAIT)
|
|
|
|
return -EAGAIN;
|
|
|
|
|
2023-01-13 11:49:10 +00:00
|
|
|
error = __remove_privs(file_mnt_idmap(file), dentry, kill);
|
2022-08-16 15:31:58 +00:00
|
|
|
}
|
2022-06-23 17:51:51 +00:00
|
|
|
|
2015-05-21 14:05:52 +00:00
|
|
|
if (!error)
|
|
|
|
inode_has_no_xattr(inode);
|
2012-05-15 06:57:33 +00:00
|
|
|
return error;
|
|
|
|
}
|
2024-02-28 23:28:48 +00:00
|
|
|
EXPORT_SYMBOL_GPL(file_remove_privs_flags);
|
2022-06-23 17:51:51 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* file_remove_privs - remove special file privileges (suid, capabilities)
|
|
|
|
* @file: file to remove privileges from
|
|
|
|
*
|
|
|
|
* When file is modified by a write or truncation ensure that special
|
|
|
|
* file privileges are removed.
|
|
|
|
*
|
|
|
|
* Return: 0 on success, negative errno on failure.
|
|
|
|
*/
|
|
|
|
int file_remove_privs(struct file *file)
|
|
|
|
{
|
2024-02-28 23:28:48 +00:00
|
|
|
return file_remove_privs_flags(file, 0);
|
2022-06-23 17:51:51 +00:00
|
|
|
}
|
2015-05-21 14:05:53 +00:00
|
|
|
EXPORT_SYMBOL(file_remove_privs);
|
2012-05-15 06:57:33 +00:00
|
|
|
|
fs: add infrastructure for multigrain timestamps
The VFS has always used coarse-grained timestamps when updating the
ctime and mtime after a change. This has the benefit of allowing
filesystems to optimize away a lot metadata updates, down to around 1
per jiffy, even when a file is under heavy writes.
Unfortunately, this has always been an issue when we're exporting via
NFSv3, which relies on timestamps to validate caches. A lot of changes
can happen in a jiffy, so timestamps aren't sufficient to help the
client decide when to invalidate the cache. Even with NFSv4, a lot of
exported filesystems don't properly support a change attribute and are
subject to the same problems with timestamp granularity. Other
applications have similar issues with timestamps (e.g backup
applications).
If fine-grained timestamps were always used, that would improve the
situation, but that becomes rather expensive, as the underlying
filesystem would have to log a lot more metadata updates.
What is needed is a way to only use fine-grained timestamps when they
are being actively queried. Use the (unused) top bit in
inode->i_ctime_nsec as a flag that indicates whether the current
timestamps have been queried via stat() or the like. When it's set,
allow the update to use a fine-grained timestamp iff it's necessary to
make the ctime show a different value.
If it has been queried, then first see whether the current coarse time
is later than the existing ctime. If it is, accept that value. If it
isn't, then get a fine-grained timestamp and attempt to stamp the inode
ctime with that value. If that races with another concurrent stamp, then
abandon the update and take the new value without retrying.
Filesystems can opt into this by setting the FS_MGTIME fstype flag.
Others should be unaffected (other than being subject to the same floor
value as multigrain filesystems).
Tested-by: Randy Dunlap <rdunlap@infradead.org> # documentation bits
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Link: https://lore.kernel.org/r/20241002-mgtime-v10-3-d1c4717f5284@kernel.org
Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-10-02 21:27:18 +00:00
|
|
|
/**
|
|
|
|
* current_time - Return FS time (possibly fine-grained)
|
|
|
|
* @inode: inode.
|
|
|
|
*
|
|
|
|
* Return the current time truncated to the time granularity supported by
|
|
|
|
* the fs, as suitable for a ctime/mtime change. If the ctime is flagged
|
|
|
|
* as having been QUERIED, get a fine-grained timestamp, but don't update
|
|
|
|
* the floor.
|
|
|
|
*
|
|
|
|
* For a multigrain inode, this is effectively an estimate of the timestamp
|
|
|
|
* that a file would receive. An actual update must go through
|
|
|
|
* inode_set_ctime_current().
|
|
|
|
*/
|
|
|
|
struct timespec64 current_time(struct inode *inode)
|
|
|
|
{
|
|
|
|
struct timespec64 now;
|
|
|
|
u32 cns;
|
|
|
|
|
|
|
|
ktime_get_coarse_real_ts64_mg(&now);
|
|
|
|
|
|
|
|
if (!is_mgtime(inode))
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
/* If nothing has queried it, then coarse time is fine */
|
|
|
|
cns = smp_load_acquire(&inode->i_ctime_nsec);
|
|
|
|
if (cns & I_CTIME_QUERIED) {
|
|
|
|
/*
|
|
|
|
* If there is no apparent change, then get a fine-grained
|
|
|
|
* timestamp.
|
|
|
|
*/
|
|
|
|
if (now.tv_nsec == (cns & ~I_CTIME_QUERIED))
|
|
|
|
ktime_get_real_ts64(&now);
|
|
|
|
}
|
|
|
|
out:
|
|
|
|
return timestamp_truncate(now, inode);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(current_time);
|
|
|
|
|
2023-08-07 19:38:39 +00:00
|
|
|
static int inode_needs_update_time(struct inode *inode)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
fs: add infrastructure for multigrain timestamps
The VFS has always used coarse-grained timestamps when updating the
ctime and mtime after a change. This has the benefit of allowing
filesystems to optimize away a lot metadata updates, down to around 1
per jiffy, even when a file is under heavy writes.
Unfortunately, this has always been an issue when we're exporting via
NFSv3, which relies on timestamps to validate caches. A lot of changes
can happen in a jiffy, so timestamps aren't sufficient to help the
client decide when to invalidate the cache. Even with NFSv4, a lot of
exported filesystems don't properly support a change attribute and are
subject to the same problems with timestamp granularity. Other
applications have similar issues with timestamps (e.g backup
applications).
If fine-grained timestamps were always used, that would improve the
situation, but that becomes rather expensive, as the underlying
filesystem would have to log a lot more metadata updates.
What is needed is a way to only use fine-grained timestamps when they
are being actively queried. Use the (unused) top bit in
inode->i_ctime_nsec as a flag that indicates whether the current
timestamps have been queried via stat() or the like. When it's set,
allow the update to use a fine-grained timestamp iff it's necessary to
make the ctime show a different value.
If it has been queried, then first see whether the current coarse time
is later than the existing ctime. If it is, accept that value. If it
isn't, then get a fine-grained timestamp and attempt to stamp the inode
ctime with that value. If that races with another concurrent stamp, then
abandon the update and take the new value without retrying.
Filesystems can opt into this by setting the FS_MGTIME fstype flag.
Others should be unaffected (other than being subject to the same floor
value as multigrain filesystems).
Tested-by: Randy Dunlap <rdunlap@infradead.org> # documentation bits
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Link: https://lore.kernel.org/r/20241002-mgtime-v10-3-d1c4717f5284@kernel.org
Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-10-02 21:27:18 +00:00
|
|
|
struct timespec64 now, ts;
|
2012-03-26 13:59:21 +00:00
|
|
|
int sync_it = 0;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2009-09-18 20:05:48 +00:00
|
|
|
/* First try to exhaust all avenues to not sync */
|
2005-04-16 22:20:36 +00:00
|
|
|
if (IS_NOCMTIME(inode))
|
2012-03-26 13:59:21 +00:00
|
|
|
return 0;
|
2008-02-15 22:37:43 +00:00
|
|
|
|
fs: add infrastructure for multigrain timestamps
The VFS has always used coarse-grained timestamps when updating the
ctime and mtime after a change. This has the benefit of allowing
filesystems to optimize away a lot metadata updates, down to around 1
per jiffy, even when a file is under heavy writes.
Unfortunately, this has always been an issue when we're exporting via
NFSv3, which relies on timestamps to validate caches. A lot of changes
can happen in a jiffy, so timestamps aren't sufficient to help the
client decide when to invalidate the cache. Even with NFSv4, a lot of
exported filesystems don't properly support a change attribute and are
subject to the same problems with timestamp granularity. Other
applications have similar issues with timestamps (e.g backup
applications).
If fine-grained timestamps were always used, that would improve the
situation, but that becomes rather expensive, as the underlying
filesystem would have to log a lot more metadata updates.
What is needed is a way to only use fine-grained timestamps when they
are being actively queried. Use the (unused) top bit in
inode->i_ctime_nsec as a flag that indicates whether the current
timestamps have been queried via stat() or the like. When it's set,
allow the update to use a fine-grained timestamp iff it's necessary to
make the ctime show a different value.
If it has been queried, then first see whether the current coarse time
is later than the existing ctime. If it is, accept that value. If it
isn't, then get a fine-grained timestamp and attempt to stamp the inode
ctime with that value. If that races with another concurrent stamp, then
abandon the update and take the new value without retrying.
Filesystems can opt into this by setting the FS_MGTIME fstype flag.
Others should be unaffected (other than being subject to the same floor
value as multigrain filesystems).
Tested-by: Randy Dunlap <rdunlap@infradead.org> # documentation bits
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Link: https://lore.kernel.org/r/20241002-mgtime-v10-3-d1c4717f5284@kernel.org
Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-10-02 21:27:18 +00:00
|
|
|
now = current_time(inode);
|
|
|
|
|
2023-10-04 18:52:38 +00:00
|
|
|
ts = inode_get_mtime(inode);
|
|
|
|
if (!timespec64_equal(&ts, &now))
|
fs: add infrastructure for multigrain timestamps
The VFS has always used coarse-grained timestamps when updating the
ctime and mtime after a change. This has the benefit of allowing
filesystems to optimize away a lot metadata updates, down to around 1
per jiffy, even when a file is under heavy writes.
Unfortunately, this has always been an issue when we're exporting via
NFSv3, which relies on timestamps to validate caches. A lot of changes
can happen in a jiffy, so timestamps aren't sufficient to help the
client decide when to invalidate the cache. Even with NFSv4, a lot of
exported filesystems don't properly support a change attribute and are
subject to the same problems with timestamp granularity. Other
applications have similar issues with timestamps (e.g backup
applications).
If fine-grained timestamps were always used, that would improve the
situation, but that becomes rather expensive, as the underlying
filesystem would have to log a lot more metadata updates.
What is needed is a way to only use fine-grained timestamps when they
are being actively queried. Use the (unused) top bit in
inode->i_ctime_nsec as a flag that indicates whether the current
timestamps have been queried via stat() or the like. When it's set,
allow the update to use a fine-grained timestamp iff it's necessary to
make the ctime show a different value.
If it has been queried, then first see whether the current coarse time
is later than the existing ctime. If it is, accept that value. If it
isn't, then get a fine-grained timestamp and attempt to stamp the inode
ctime with that value. If that races with another concurrent stamp, then
abandon the update and take the new value without retrying.
Filesystems can opt into this by setting the FS_MGTIME fstype flag.
Others should be unaffected (other than being subject to the same floor
value as multigrain filesystems).
Tested-by: Randy Dunlap <rdunlap@infradead.org> # documentation bits
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Link: https://lore.kernel.org/r/20241002-mgtime-v10-3-d1c4717f5284@kernel.org
Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-10-02 21:27:18 +00:00
|
|
|
sync_it |= S_MTIME;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2023-10-04 18:52:38 +00:00
|
|
|
ts = inode_get_ctime(inode);
|
|
|
|
if (!timespec64_equal(&ts, &now))
|
2009-09-18 20:05:48 +00:00
|
|
|
sync_it |= S_CTIME;
|
2006-01-10 04:52:01 +00:00
|
|
|
|
2017-12-11 11:35:22 +00:00
|
|
|
if (IS_I_VERSION(inode) && inode_iversion_need_inc(inode))
|
2009-09-18 20:05:48 +00:00
|
|
|
sync_it |= S_VERSION;
|
2008-01-29 04:58:27 +00:00
|
|
|
|
2022-06-23 17:51:52 +00:00
|
|
|
return sync_it;
|
|
|
|
}
|
|
|
|
|
2023-08-07 19:38:39 +00:00
|
|
|
static int __file_update_time(struct file *file, int sync_mode)
|
2022-06-23 17:51:52 +00:00
|
|
|
{
|
|
|
|
int ret = 0;
|
|
|
|
struct inode *inode = file_inode(file);
|
2009-09-18 20:05:48 +00:00
|
|
|
|
2022-06-23 17:51:52 +00:00
|
|
|
/* try to update time settings */
|
2023-09-08 13:28:59 +00:00
|
|
|
if (!mnt_get_write_access_file(file)) {
|
2023-08-07 19:38:39 +00:00
|
|
|
ret = inode_update_time(inode, sync_mode);
|
2023-09-08 13:28:59 +00:00
|
|
|
mnt_put_write_access_file(file);
|
2022-06-23 17:51:52 +00:00
|
|
|
}
|
2012-03-26 13:59:21 +00:00
|
|
|
|
|
|
|
return ret;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
2022-06-23 17:51:52 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* file_update_time - update mtime and ctime time
|
|
|
|
* @file: file accessed
|
|
|
|
*
|
|
|
|
* Update the mtime and ctime members of an inode and mark the inode for
|
|
|
|
* writeback. Note that this function is meant exclusively for usage in
|
|
|
|
* the file write path of filesystems, and filesystems may choose to
|
|
|
|
* explicitly ignore updates via this function with the _NOCMTIME inode
|
|
|
|
* flag, e.g. for network filesystem where these imestamps are handled
|
|
|
|
* by the server. This can return an error for file systems who need to
|
|
|
|
* allocate space in order to update an inode.
|
|
|
|
*
|
|
|
|
* Return: 0 on success, negative errno on failure.
|
|
|
|
*/
|
|
|
|
int file_update_time(struct file *file)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
struct inode *inode = file_inode(file);
|
|
|
|
|
2023-08-07 19:38:39 +00:00
|
|
|
ret = inode_needs_update_time(inode);
|
2022-06-23 17:51:52 +00:00
|
|
|
if (ret <= 0)
|
|
|
|
return ret;
|
|
|
|
|
2023-08-07 19:38:39 +00:00
|
|
|
return __file_update_time(file, ret);
|
2022-06-23 17:51:52 +00:00
|
|
|
}
|
2006-01-10 04:52:01 +00:00
|
|
|
EXPORT_SYMBOL(file_update_time);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2022-06-23 17:51:51 +00:00
|
|
|
/**
|
2022-06-23 17:51:53 +00:00
|
|
|
* file_modified_flags - handle mandated vfs changes when modifying a file
|
2022-06-23 17:51:51 +00:00
|
|
|
* @file: file that was modified
|
2022-06-23 17:51:53 +00:00
|
|
|
* @flags: kiocb flags
|
2022-06-23 17:51:51 +00:00
|
|
|
*
|
|
|
|
* When file has been modified ensure that special
|
|
|
|
* file privileges are removed and time settings are updated.
|
|
|
|
*
|
2022-06-23 17:51:53 +00:00
|
|
|
* If IOCB_NOWAIT is set, special file privileges will not be removed and
|
|
|
|
* time settings will not be updated. It will return -EAGAIN.
|
|
|
|
*
|
2022-06-23 17:51:51 +00:00
|
|
|
* Context: Caller must hold the file's inode lock.
|
|
|
|
*
|
|
|
|
* Return: 0 on success, negative errno on failure.
|
|
|
|
*/
|
2022-06-23 17:51:53 +00:00
|
|
|
static int file_modified_flags(struct file *file, int flags)
|
2019-06-05 15:04:49 +00:00
|
|
|
{
|
2022-06-23 17:51:51 +00:00
|
|
|
int ret;
|
2022-06-23 17:51:52 +00:00
|
|
|
struct inode *inode = file_inode(file);
|
2019-06-05 15:04:49 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Clear the security bits if the process is not being run by root.
|
|
|
|
* This keeps people from modifying setuid and setgid binaries.
|
|
|
|
*/
|
2024-02-28 23:28:48 +00:00
|
|
|
ret = file_remove_privs_flags(file, flags);
|
2022-06-23 17:51:51 +00:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
2019-06-05 15:04:49 +00:00
|
|
|
|
|
|
|
if (unlikely(file->f_mode & FMODE_NOCMTIME))
|
|
|
|
return 0;
|
|
|
|
|
2023-08-07 19:38:39 +00:00
|
|
|
ret = inode_needs_update_time(inode);
|
2022-06-23 17:51:52 +00:00
|
|
|
if (ret <= 0)
|
|
|
|
return ret;
|
2022-06-23 17:51:53 +00:00
|
|
|
if (flags & IOCB_NOWAIT)
|
|
|
|
return -EAGAIN;
|
2022-06-23 17:51:52 +00:00
|
|
|
|
2023-08-07 19:38:39 +00:00
|
|
|
return __file_update_time(file, ret);
|
2019-06-05 15:04:49 +00:00
|
|
|
}
|
2022-06-23 17:51:53 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* file_modified - handle mandated vfs changes when modifying a file
|
|
|
|
* @file: file that was modified
|
|
|
|
*
|
|
|
|
* When file has been modified ensure that special
|
|
|
|
* file privileges are removed and time settings are updated.
|
|
|
|
*
|
|
|
|
* Context: Caller must hold the file's inode lock.
|
|
|
|
*
|
|
|
|
* Return: 0 on success, negative errno on failure.
|
|
|
|
*/
|
|
|
|
int file_modified(struct file *file)
|
|
|
|
{
|
|
|
|
return file_modified_flags(file, 0);
|
|
|
|
}
|
2019-06-05 15:04:49 +00:00
|
|
|
EXPORT_SYMBOL(file_modified);
|
|
|
|
|
2022-06-23 17:51:53 +00:00
|
|
|
/**
|
|
|
|
* kiocb_modified - handle mandated vfs changes when modifying a file
|
|
|
|
* @iocb: iocb that was modified
|
|
|
|
*
|
|
|
|
* When file has been modified ensure that special
|
|
|
|
* file privileges are removed and time settings are updated.
|
|
|
|
*
|
|
|
|
* Context: Caller must hold the file's inode lock.
|
|
|
|
*
|
|
|
|
* Return: 0 on success, negative errno on failure.
|
|
|
|
*/
|
|
|
|
int kiocb_modified(struct kiocb *iocb)
|
|
|
|
{
|
|
|
|
return file_modified_flags(iocb->ki_filp, iocb->ki_flags);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(kiocb_modified);
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
int inode_needs_sync(struct inode *inode)
|
|
|
|
{
|
|
|
|
if (IS_SYNC(inode))
|
|
|
|
return 1;
|
|
|
|
if (S_ISDIR(inode->i_mode) && IS_DIRSYNC(inode))
|
|
|
|
return 1;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(inode_needs_sync);
|
|
|
|
|
|
|
|
/*
|
2005-07-12 20:58:10 +00:00
|
|
|
* If we try to find an inode in the inode hash while it is being
|
|
|
|
* deleted, we have to wait until the filesystem completes its
|
|
|
|
* deletion before reporting that it isn't found. This function waits
|
|
|
|
* until the deletion _might_ have completed. Callers are responsible
|
|
|
|
* to recheck inode state.
|
|
|
|
*
|
2009-12-17 13:25:01 +00:00
|
|
|
* It doesn't matter if I_NEW is not set initially, a call to
|
2011-03-22 11:23:36 +00:00
|
|
|
* wake_up_bit(&inode->i_state, __I_NEW) after removing from the hash list
|
|
|
|
* will DTRT.
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
2024-07-24 08:50:33 +00:00
|
|
|
static void __wait_on_freeing_inode(struct inode *inode, bool is_inode_hash_locked)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2024-08-23 12:47:38 +00:00
|
|
|
struct wait_bit_queue_entry wqe;
|
|
|
|
struct wait_queue_head *wq_head;
|
2024-07-18 15:18:37 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Handle racing against evict(), see that routine for more details.
|
|
|
|
*/
|
|
|
|
if (unlikely(inode_unhashed(inode))) {
|
2024-07-24 08:50:33 +00:00
|
|
|
WARN_ON(is_inode_hash_locked);
|
2024-07-18 15:18:37 +00:00
|
|
|
spin_unlock(&inode->i_lock);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2024-08-23 12:47:38 +00:00
|
|
|
wq_head = inode_bit_waitqueue(&wqe, inode, __I_NEW);
|
|
|
|
prepare_to_wait_event(wq_head, &wqe.wq_entry, TASK_UNINTERRUPTIBLE);
|
2011-03-22 11:23:36 +00:00
|
|
|
spin_unlock(&inode->i_lock);
|
vfs: add rcu-based find_inode variants for iget ops
This avoids one inode hash lock acquire in the common case on inode
creation, in effect significantly reducing contention.
On the stock kernel said lock is typically taken twice:
1. once to check if the inode happens to already be present
2. once to add it to the hash
The back-to-back lock/unlock pattern is known to degrade performance
significantly, which is further exacerbated if the hash is heavily
populated (long chains to walk, extending hold time). Arguably hash
sizing and hashing algo need to be revisited, but that's beyond the
scope of this patch.
With the acquire from step 1 eliminated with RCU lookup throughput
increases significantly at the scale of 20 cores (benchmark results at
the bottom).
So happens the hash already supports RCU-based operation, but lookups on
inode insertions didn't take advantage of it.
This of course has its limits as the global lock is still a bottleneck.
There was a patchset posted which introduced fine-grained locking[1] but
it appears staled. Apart from that doubt was expressed whether a
handrolled hash implementation is appropriate to begin with, suggesting
replacement with rhashtables. Nobody committed to carrying [1] across
the finish line or implementing anything better, thus the bandaid below.
iget_locked consumers (notably ext4) get away without any changes
because inode comparison method is built-in.
iget5_locked consumers pass a custom callback. Since removal of locking
adds more problems (inode can be changing) it's not safe to assume all
filesystems happen to cope. Thus iget5_locked_rcu gets added, requiring
manual conversion of interested filesystems.
In order to reduce code duplication find_inode and find_inode_fast grow
an argument indicating whether inode hash lock is held, which is passed
down in case sleeping is necessary. They always rcu_read_lock, which is
redundant but harmless. Doing it conditionally reduces readability for
no real gain that I can see. RCU-alike restrictions were already put on
callbacks due to the hash spinlock being held.
Benchmarking:
There is a real cache-busting workload scanning millions of files in
parallel (it's a backup appliance), where the initial lookup is
guaranteed to fail resulting in the two lock acquires on stock kernel
(and one with the patch at hand).
Implemented below is a synthetic benchmark providing the same behavior.
[I shall note the workload is not running on Linux, instead it was
causing trouble elsewhere. Benchmark below was used while addressing
said problems and was found to adequately represent the real workload.]
Total real time fluctuates by 1-2s.
With 20 threads each walking a dedicated 1000 dirs * 1000 files
directory tree to stat(2) on a 32 core + 24GB RAM vm:
ext4 (needed mkfs.ext4 -N 24000000):
before: 3.77s user 890.90s system 1939% cpu 46.118 total
after: 3.24s user 397.73s system 1858% cpu 21.581 total (-53%)
That's 20 million files to visit, while the machine can only cache about
15 million at a time (obtained from ext4_inode_cache object count in
/proc/slabinfo). Since each terminal inode is only visited once per run
this amounts to 0% hit ratio for the dentry cache and the hash table
(there are however hits for the intermediate directories).
On repeated runs the kernel caches the last ~15 mln, meaning there is ~5
mln of uncached inodes which are going to be visited first, evicting the
previously cached state as it happens.
Lack of hits can be trivially verified with bpftrace, like so:
bpftrace -e 'kretprobe:find_inode_fast { @[kstack(), retval != 0] = count(); }'\
-c "/bin/sh walktrees /testfs 20"
Best ran more than once.
Expected results after "warmup":
[snip]
@[
__ext4_iget+275
ext4_lookup+224
__lookup_slow+130
walk_component+219
link_path_walk.part.0.constprop.0+614
path_lookupat+62
filename_lookup+204
vfs_statx+128
vfs_fstatat+131
__do_sys_newfstatat+38
do_syscall_64+87
entry_SYSCALL_64_after_hwframe+118
, 1]: 20000
@[
__ext4_iget+275
ext4_lookup+224
__lookup_slow+130
walk_component+219
path_lookupat+106
filename_lookup+204
vfs_statx+128
vfs_fstatat+131
__do_sys_newfstatat+38
do_syscall_64+87
entry_SYSCALL_64_after_hwframe+118
, 1]: 20000000
That is 20 million calls for the initial lookup and 20 million after
allocating a new inode, all of them failing to return a value != 0
(i.e., they are returning NULL -- no match found).
Of course aborting the benchmark in the middle and starting it again (or
messing with the state in other ways) is going to alter these results.
Benchmark can be found here: https://people.freebsd.org/~mjg/fstree.tgz
[1] https://lore.kernel.org/all/20231206060629.2827226-1-david@fromorbit.com/
Signed-off-by: Mateusz Guzik <mjguzik@gmail.com>
Link: https://lore.kernel.org/r/20240611173824.535995-2-mjguzik@gmail.com
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-06-11 17:38:22 +00:00
|
|
|
rcu_read_unlock();
|
2024-07-24 08:50:33 +00:00
|
|
|
if (is_inode_hash_locked)
|
vfs: add rcu-based find_inode variants for iget ops
This avoids one inode hash lock acquire in the common case on inode
creation, in effect significantly reducing contention.
On the stock kernel said lock is typically taken twice:
1. once to check if the inode happens to already be present
2. once to add it to the hash
The back-to-back lock/unlock pattern is known to degrade performance
significantly, which is further exacerbated if the hash is heavily
populated (long chains to walk, extending hold time). Arguably hash
sizing and hashing algo need to be revisited, but that's beyond the
scope of this patch.
With the acquire from step 1 eliminated with RCU lookup throughput
increases significantly at the scale of 20 cores (benchmark results at
the bottom).
So happens the hash already supports RCU-based operation, but lookups on
inode insertions didn't take advantage of it.
This of course has its limits as the global lock is still a bottleneck.
There was a patchset posted which introduced fine-grained locking[1] but
it appears staled. Apart from that doubt was expressed whether a
handrolled hash implementation is appropriate to begin with, suggesting
replacement with rhashtables. Nobody committed to carrying [1] across
the finish line or implementing anything better, thus the bandaid below.
iget_locked consumers (notably ext4) get away without any changes
because inode comparison method is built-in.
iget5_locked consumers pass a custom callback. Since removal of locking
adds more problems (inode can be changing) it's not safe to assume all
filesystems happen to cope. Thus iget5_locked_rcu gets added, requiring
manual conversion of interested filesystems.
In order to reduce code duplication find_inode and find_inode_fast grow
an argument indicating whether inode hash lock is held, which is passed
down in case sleeping is necessary. They always rcu_read_lock, which is
redundant but harmless. Doing it conditionally reduces readability for
no real gain that I can see. RCU-alike restrictions were already put on
callbacks due to the hash spinlock being held.
Benchmarking:
There is a real cache-busting workload scanning millions of files in
parallel (it's a backup appliance), where the initial lookup is
guaranteed to fail resulting in the two lock acquires on stock kernel
(and one with the patch at hand).
Implemented below is a synthetic benchmark providing the same behavior.
[I shall note the workload is not running on Linux, instead it was
causing trouble elsewhere. Benchmark below was used while addressing
said problems and was found to adequately represent the real workload.]
Total real time fluctuates by 1-2s.
With 20 threads each walking a dedicated 1000 dirs * 1000 files
directory tree to stat(2) on a 32 core + 24GB RAM vm:
ext4 (needed mkfs.ext4 -N 24000000):
before: 3.77s user 890.90s system 1939% cpu 46.118 total
after: 3.24s user 397.73s system 1858% cpu 21.581 total (-53%)
That's 20 million files to visit, while the machine can only cache about
15 million at a time (obtained from ext4_inode_cache object count in
/proc/slabinfo). Since each terminal inode is only visited once per run
this amounts to 0% hit ratio for the dentry cache and the hash table
(there are however hits for the intermediate directories).
On repeated runs the kernel caches the last ~15 mln, meaning there is ~5
mln of uncached inodes which are going to be visited first, evicting the
previously cached state as it happens.
Lack of hits can be trivially verified with bpftrace, like so:
bpftrace -e 'kretprobe:find_inode_fast { @[kstack(), retval != 0] = count(); }'\
-c "/bin/sh walktrees /testfs 20"
Best ran more than once.
Expected results after "warmup":
[snip]
@[
__ext4_iget+275
ext4_lookup+224
__lookup_slow+130
walk_component+219
link_path_walk.part.0.constprop.0+614
path_lookupat+62
filename_lookup+204
vfs_statx+128
vfs_fstatat+131
__do_sys_newfstatat+38
do_syscall_64+87
entry_SYSCALL_64_after_hwframe+118
, 1]: 20000
@[
__ext4_iget+275
ext4_lookup+224
__lookup_slow+130
walk_component+219
path_lookupat+106
filename_lookup+204
vfs_statx+128
vfs_fstatat+131
__do_sys_newfstatat+38
do_syscall_64+87
entry_SYSCALL_64_after_hwframe+118
, 1]: 20000000
That is 20 million calls for the initial lookup and 20 million after
allocating a new inode, all of them failing to return a value != 0
(i.e., they are returning NULL -- no match found).
Of course aborting the benchmark in the middle and starting it again (or
messing with the state in other ways) is going to alter these results.
Benchmark can be found here: https://people.freebsd.org/~mjg/fstree.tgz
[1] https://lore.kernel.org/all/20231206060629.2827226-1-david@fromorbit.com/
Signed-off-by: Mateusz Guzik <mjguzik@gmail.com>
Link: https://lore.kernel.org/r/20240611173824.535995-2-mjguzik@gmail.com
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-06-11 17:38:22 +00:00
|
|
|
spin_unlock(&inode_hash_lock);
|
2005-04-16 22:20:36 +00:00
|
|
|
schedule();
|
2024-08-23 12:47:38 +00:00
|
|
|
finish_wait(wq_head, &wqe.wq_entry);
|
2024-07-24 08:50:33 +00:00
|
|
|
if (is_inode_hash_locked)
|
vfs: add rcu-based find_inode variants for iget ops
This avoids one inode hash lock acquire in the common case on inode
creation, in effect significantly reducing contention.
On the stock kernel said lock is typically taken twice:
1. once to check if the inode happens to already be present
2. once to add it to the hash
The back-to-back lock/unlock pattern is known to degrade performance
significantly, which is further exacerbated if the hash is heavily
populated (long chains to walk, extending hold time). Arguably hash
sizing and hashing algo need to be revisited, but that's beyond the
scope of this patch.
With the acquire from step 1 eliminated with RCU lookup throughput
increases significantly at the scale of 20 cores (benchmark results at
the bottom).
So happens the hash already supports RCU-based operation, but lookups on
inode insertions didn't take advantage of it.
This of course has its limits as the global lock is still a bottleneck.
There was a patchset posted which introduced fine-grained locking[1] but
it appears staled. Apart from that doubt was expressed whether a
handrolled hash implementation is appropriate to begin with, suggesting
replacement with rhashtables. Nobody committed to carrying [1] across
the finish line or implementing anything better, thus the bandaid below.
iget_locked consumers (notably ext4) get away without any changes
because inode comparison method is built-in.
iget5_locked consumers pass a custom callback. Since removal of locking
adds more problems (inode can be changing) it's not safe to assume all
filesystems happen to cope. Thus iget5_locked_rcu gets added, requiring
manual conversion of interested filesystems.
In order to reduce code duplication find_inode and find_inode_fast grow
an argument indicating whether inode hash lock is held, which is passed
down in case sleeping is necessary. They always rcu_read_lock, which is
redundant but harmless. Doing it conditionally reduces readability for
no real gain that I can see. RCU-alike restrictions were already put on
callbacks due to the hash spinlock being held.
Benchmarking:
There is a real cache-busting workload scanning millions of files in
parallel (it's a backup appliance), where the initial lookup is
guaranteed to fail resulting in the two lock acquires on stock kernel
(and one with the patch at hand).
Implemented below is a synthetic benchmark providing the same behavior.
[I shall note the workload is not running on Linux, instead it was
causing trouble elsewhere. Benchmark below was used while addressing
said problems and was found to adequately represent the real workload.]
Total real time fluctuates by 1-2s.
With 20 threads each walking a dedicated 1000 dirs * 1000 files
directory tree to stat(2) on a 32 core + 24GB RAM vm:
ext4 (needed mkfs.ext4 -N 24000000):
before: 3.77s user 890.90s system 1939% cpu 46.118 total
after: 3.24s user 397.73s system 1858% cpu 21.581 total (-53%)
That's 20 million files to visit, while the machine can only cache about
15 million at a time (obtained from ext4_inode_cache object count in
/proc/slabinfo). Since each terminal inode is only visited once per run
this amounts to 0% hit ratio for the dentry cache and the hash table
(there are however hits for the intermediate directories).
On repeated runs the kernel caches the last ~15 mln, meaning there is ~5
mln of uncached inodes which are going to be visited first, evicting the
previously cached state as it happens.
Lack of hits can be trivially verified with bpftrace, like so:
bpftrace -e 'kretprobe:find_inode_fast { @[kstack(), retval != 0] = count(); }'\
-c "/bin/sh walktrees /testfs 20"
Best ran more than once.
Expected results after "warmup":
[snip]
@[
__ext4_iget+275
ext4_lookup+224
__lookup_slow+130
walk_component+219
link_path_walk.part.0.constprop.0+614
path_lookupat+62
filename_lookup+204
vfs_statx+128
vfs_fstatat+131
__do_sys_newfstatat+38
do_syscall_64+87
entry_SYSCALL_64_after_hwframe+118
, 1]: 20000
@[
__ext4_iget+275
ext4_lookup+224
__lookup_slow+130
walk_component+219
path_lookupat+106
filename_lookup+204
vfs_statx+128
vfs_fstatat+131
__do_sys_newfstatat+38
do_syscall_64+87
entry_SYSCALL_64_after_hwframe+118
, 1]: 20000000
That is 20 million calls for the initial lookup and 20 million after
allocating a new inode, all of them failing to return a value != 0
(i.e., they are returning NULL -- no match found).
Of course aborting the benchmark in the middle and starting it again (or
messing with the state in other ways) is going to alter these results.
Benchmark can be found here: https://people.freebsd.org/~mjg/fstree.tgz
[1] https://lore.kernel.org/all/20231206060629.2827226-1-david@fromorbit.com/
Signed-off-by: Mateusz Guzik <mjguzik@gmail.com>
Link: https://lore.kernel.org/r/20240611173824.535995-2-mjguzik@gmail.com
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-06-11 17:38:22 +00:00
|
|
|
spin_lock(&inode_hash_lock);
|
|
|
|
rcu_read_lock();
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static __initdata unsigned long ihash_entries;
|
|
|
|
static int __init set_ihash_entries(char *str)
|
|
|
|
{
|
|
|
|
if (!str)
|
|
|
|
return 0;
|
|
|
|
ihash_entries = simple_strtoul(str, &str, 0);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
__setup("ihash_entries=", set_ihash_entries);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Initialize the waitqueues and inode hash table.
|
|
|
|
*/
|
|
|
|
void __init inode_init_early(void)
|
|
|
|
{
|
|
|
|
/* If hashes are distributed across NUMA nodes, defer
|
|
|
|
* hash allocation until vmalloc space is available.
|
|
|
|
*/
|
|
|
|
if (hashdist)
|
|
|
|
return;
|
|
|
|
|
|
|
|
inode_hashtable =
|
|
|
|
alloc_large_system_hash("Inode-cache",
|
|
|
|
sizeof(struct hlist_head),
|
|
|
|
ihash_entries,
|
|
|
|
14,
|
2017-07-06 22:39:11 +00:00
|
|
|
HASH_EARLY | HASH_ZERO,
|
2005-04-16 22:20:36 +00:00
|
|
|
&i_hash_shift,
|
|
|
|
&i_hash_mask,
|
2012-05-23 13:33:35 +00:00
|
|
|
0,
|
2005-04-16 22:20:36 +00:00
|
|
|
0);
|
|
|
|
}
|
|
|
|
|
2007-10-17 06:26:30 +00:00
|
|
|
void __init inode_init(void)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
|
|
|
/* inode slab cache */
|
2006-03-24 11:16:09 +00:00
|
|
|
inode_cachep = kmem_cache_create("inode_cache",
|
|
|
|
sizeof(struct inode),
|
|
|
|
0,
|
|
|
|
(SLAB_RECLAIM_ACCOUNT|SLAB_PANIC|
|
2024-02-24 13:53:15 +00:00
|
|
|
SLAB_ACCOUNT),
|
2007-07-20 01:11:58 +00:00
|
|
|
init_once);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
/* Hash may have been set up in inode_init_early */
|
|
|
|
if (!hashdist)
|
|
|
|
return;
|
|
|
|
|
|
|
|
inode_hashtable =
|
|
|
|
alloc_large_system_hash("Inode-cache",
|
|
|
|
sizeof(struct hlist_head),
|
|
|
|
ihash_entries,
|
|
|
|
14,
|
2017-07-06 22:39:11 +00:00
|
|
|
HASH_ZERO,
|
2005-04-16 22:20:36 +00:00
|
|
|
&i_hash_shift,
|
|
|
|
&i_hash_mask,
|
2012-05-23 13:33:35 +00:00
|
|
|
0,
|
2005-04-16 22:20:36 +00:00
|
|
|
0);
|
|
|
|
}
|
|
|
|
|
|
|
|
void init_special_inode(struct inode *inode, umode_t mode, dev_t rdev)
|
|
|
|
{
|
|
|
|
inode->i_mode = mode;
|
|
|
|
if (S_ISCHR(mode)) {
|
|
|
|
inode->i_fop = &def_chr_fops;
|
|
|
|
inode->i_rdev = rdev;
|
|
|
|
} else if (S_ISBLK(mode)) {
|
2023-05-08 14:44:05 +00:00
|
|
|
if (IS_ENABLED(CONFIG_BLOCK))
|
|
|
|
inode->i_fop = &def_blk_fops;
|
2005-04-16 22:20:36 +00:00
|
|
|
inode->i_rdev = rdev;
|
|
|
|
} else if (S_ISFIFO(mode))
|
2013-03-12 13:58:10 +00:00
|
|
|
inode->i_fop = &pipefifo_fops;
|
2005-04-16 22:20:36 +00:00
|
|
|
else if (S_ISSOCK(mode))
|
2014-11-19 04:38:21 +00:00
|
|
|
; /* leave it no_open_fops */
|
2005-04-16 22:20:36 +00:00
|
|
|
else
|
2009-09-18 20:05:43 +00:00
|
|
|
printk(KERN_DEBUG "init_special_inode: bogus i_mode (%o) for"
|
|
|
|
" inode %s:%lu\n", mode, inode->i_sb->s_id,
|
|
|
|
inode->i_ino);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(init_special_inode);
|
2010-03-04 14:29:14 +00:00
|
|
|
|
|
|
|
/**
|
2011-02-15 12:48:09 +00:00
|
|
|
* inode_init_owner - Init uid,gid,mode for new inode according to posix standards
|
2023-01-13 11:49:25 +00:00
|
|
|
* @idmap: idmap of the mount the inode was created from
|
2010-03-04 14:29:14 +00:00
|
|
|
* @inode: New inode
|
|
|
|
* @dir: Directory inode
|
|
|
|
* @mode: mode of the new inode
|
2021-01-21 13:19:25 +00:00
|
|
|
*
|
2023-01-13 11:49:25 +00:00
|
|
|
* If the inode has been created through an idmapped mount the idmap of
|
|
|
|
* the vfsmount must be passed through @idmap. This function will then take
|
|
|
|
* care to map the inode according to @idmap before checking permissions
|
2021-01-21 13:19:25 +00:00
|
|
|
* and initializing i_uid and i_gid. On non-idmapped mounts or if permission
|
2023-01-13 11:49:25 +00:00
|
|
|
* checking is to be performed on the raw inode simply pass @nop_mnt_idmap.
|
2010-03-04 14:29:14 +00:00
|
|
|
*/
|
2023-01-13 11:49:25 +00:00
|
|
|
void inode_init_owner(struct mnt_idmap *idmap, struct inode *inode,
|
2021-01-21 13:19:25 +00:00
|
|
|
const struct inode *dir, umode_t mode)
|
2010-03-04 14:29:14 +00:00
|
|
|
{
|
2023-01-13 11:49:31 +00:00
|
|
|
inode_fsuid_set(inode, idmap);
|
2010-03-04 14:29:14 +00:00
|
|
|
if (dir && dir->i_mode & S_ISGID) {
|
|
|
|
inode->i_gid = dir->i_gid;
|
2018-07-04 00:10:19 +00:00
|
|
|
|
|
|
|
/* Directories are special, and always inherit S_ISGID */
|
2010-03-04 14:29:14 +00:00
|
|
|
if (S_ISDIR(mode))
|
|
|
|
mode |= S_ISGID;
|
|
|
|
} else
|
2023-01-13 11:49:31 +00:00
|
|
|
inode_fsgid_set(inode, idmap);
|
2010-03-04 14:29:14 +00:00
|
|
|
inode->i_mode = mode;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(inode_init_owner);
|
2011-03-23 23:43:25 +00:00
|
|
|
|
2011-03-23 23:43:26 +00:00
|
|
|
/**
|
|
|
|
* inode_owner_or_capable - check current task permissions to inode
|
2023-01-13 11:49:26 +00:00
|
|
|
* @idmap: idmap of the mount the inode was found from
|
2011-03-23 23:43:26 +00:00
|
|
|
* @inode: inode being checked
|
|
|
|
*
|
2014-06-10 19:45:42 +00:00
|
|
|
* Return true if current either has CAP_FOWNER in a namespace with the
|
|
|
|
* inode owner uid mapped, or owns the file.
|
2021-01-21 13:19:25 +00:00
|
|
|
*
|
2023-01-13 11:49:26 +00:00
|
|
|
* If the inode has been found through an idmapped mount the idmap of
|
|
|
|
* the vfsmount must be passed through @idmap. This function will then take
|
|
|
|
* care to map the inode according to @idmap before checking permissions.
|
2021-01-21 13:19:25 +00:00
|
|
|
* On non-idmapped mounts or if permission checking is to be performed on the
|
2023-12-15 13:09:27 +00:00
|
|
|
* raw inode simply pass @nop_mnt_idmap.
|
2011-03-23 23:43:25 +00:00
|
|
|
*/
|
2023-01-13 11:49:26 +00:00
|
|
|
bool inode_owner_or_capable(struct mnt_idmap *idmap,
|
2021-01-21 13:19:25 +00:00
|
|
|
const struct inode *inode)
|
2011-03-23 23:43:25 +00:00
|
|
|
{
|
2022-06-22 20:12:16 +00:00
|
|
|
vfsuid_t vfsuid;
|
2014-06-10 19:45:42 +00:00
|
|
|
struct user_namespace *ns;
|
|
|
|
|
2023-01-13 11:49:30 +00:00
|
|
|
vfsuid = i_uid_into_vfsuid(idmap, inode);
|
2022-06-22 20:12:16 +00:00
|
|
|
if (vfsuid_eq_kuid(vfsuid, current_fsuid()))
|
2011-03-23 23:43:25 +00:00
|
|
|
return true;
|
2014-06-10 19:45:42 +00:00
|
|
|
|
|
|
|
ns = current_user_ns();
|
2022-06-22 20:12:16 +00:00
|
|
|
if (vfsuid_has_mapping(ns, vfsuid) && ns_capable(ns, CAP_FOWNER))
|
2011-03-23 23:43:25 +00:00
|
|
|
return true;
|
|
|
|
return false;
|
|
|
|
}
|
2011-03-23 23:43:26 +00:00
|
|
|
EXPORT_SYMBOL(inode_owner_or_capable);
|
2012-05-31 16:22:33 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Direct i/o helper functions
|
|
|
|
*/
|
2024-08-16 14:35:52 +00:00
|
|
|
bool inode_dio_finished(const struct inode *inode)
|
2012-05-31 16:22:33 +00:00
|
|
|
{
|
2024-08-16 14:35:52 +00:00
|
|
|
return atomic_read(&inode->i_dio_count) == 0;
|
2012-05-31 16:22:33 +00:00
|
|
|
}
|
2024-08-16 14:35:52 +00:00
|
|
|
EXPORT_SYMBOL(inode_dio_finished);
|
2012-05-31 16:22:33 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* inode_dio_wait - wait for outstanding DIO requests to finish
|
|
|
|
* @inode: inode to wait for
|
|
|
|
*
|
|
|
|
* Waits for all pending direct I/O requests to finish so that we can
|
|
|
|
* proceed with a truncate or equivalent operation.
|
|
|
|
*
|
|
|
|
* Must be called under a lock that serializes taking new references
|
|
|
|
* to i_dio_count, usually by inode->i_mutex.
|
|
|
|
*/
|
|
|
|
void inode_dio_wait(struct inode *inode)
|
|
|
|
{
|
2024-08-16 14:35:52 +00:00
|
|
|
wait_var_event(&inode->i_dio_count, inode_dio_finished(inode));
|
2012-05-31 16:22:33 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(inode_dio_wait);
|
|
|
|
|
2024-08-16 14:35:52 +00:00
|
|
|
void inode_dio_wait_interruptible(struct inode *inode)
|
|
|
|
{
|
|
|
|
wait_var_event_interruptible(&inode->i_dio_count,
|
|
|
|
inode_dio_finished(inode));
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(inode_dio_wait_interruptible);
|
|
|
|
|
2014-03-24 18:43:12 +00:00
|
|
|
/*
|
|
|
|
* inode_set_flags - atomically set some inode flags
|
|
|
|
*
|
|
|
|
* Note: the caller should be holding i_mutex, or else be sure that
|
|
|
|
* they have exclusive access to the inode structure (i.e., while the
|
|
|
|
* inode is being instantiated). The reason for the cmpxchg() loop
|
|
|
|
* --- which wouldn't be necessary if all code paths which modify
|
|
|
|
* i_flags actually followed this rule, is that there is at least one
|
2015-05-21 14:05:53 +00:00
|
|
|
* code path which doesn't today so we use cmpxchg() out of an abundance
|
|
|
|
* of caution.
|
2014-03-24 18:43:12 +00:00
|
|
|
*
|
|
|
|
* In the long run, i_mutex is overkill, and we should probably look
|
|
|
|
* at using the i_lock spinlock to protect i_flags, and then make sure
|
|
|
|
* it is so documented in include/linux/fs.h and that all code follows
|
|
|
|
* the locking convention!!
|
|
|
|
*/
|
|
|
|
void inode_set_flags(struct inode *inode, unsigned int flags,
|
|
|
|
unsigned int mask)
|
|
|
|
{
|
|
|
|
WARN_ON_ONCE(flags & ~mask);
|
2019-03-05 23:41:52 +00:00
|
|
|
set_mask_bits(&inode->i_flags, mask, flags);
|
2014-03-24 18:43:12 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(inode_set_flags);
|
2015-11-17 06:07:57 +00:00
|
|
|
|
|
|
|
void inode_nohighmem(struct inode *inode)
|
|
|
|
{
|
|
|
|
mapping_set_gfp_mask(inode->i_mapping, GFP_USER);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(inode_nohighmem);
|
2016-09-14 14:48:02 +00:00
|
|
|
|
fs: add infrastructure for multigrain timestamps
The VFS has always used coarse-grained timestamps when updating the
ctime and mtime after a change. This has the benefit of allowing
filesystems to optimize away a lot metadata updates, down to around 1
per jiffy, even when a file is under heavy writes.
Unfortunately, this has always been an issue when we're exporting via
NFSv3, which relies on timestamps to validate caches. A lot of changes
can happen in a jiffy, so timestamps aren't sufficient to help the
client decide when to invalidate the cache. Even with NFSv4, a lot of
exported filesystems don't properly support a change attribute and are
subject to the same problems with timestamp granularity. Other
applications have similar issues with timestamps (e.g backup
applications).
If fine-grained timestamps were always used, that would improve the
situation, but that becomes rather expensive, as the underlying
filesystem would have to log a lot more metadata updates.
What is needed is a way to only use fine-grained timestamps when they
are being actively queried. Use the (unused) top bit in
inode->i_ctime_nsec as a flag that indicates whether the current
timestamps have been queried via stat() or the like. When it's set,
allow the update to use a fine-grained timestamp iff it's necessary to
make the ctime show a different value.
If it has been queried, then first see whether the current coarse time
is later than the existing ctime. If it is, accept that value. If it
isn't, then get a fine-grained timestamp and attempt to stamp the inode
ctime with that value. If that races with another concurrent stamp, then
abandon the update and take the new value without retrying.
Filesystems can opt into this by setting the FS_MGTIME fstype flag.
Others should be unaffected (other than being subject to the same floor
value as multigrain filesystems).
Tested-by: Randy Dunlap <rdunlap@infradead.org> # documentation bits
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Link: https://lore.kernel.org/r/20241002-mgtime-v10-3-d1c4717f5284@kernel.org
Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-10-02 21:27:18 +00:00
|
|
|
struct timespec64 inode_set_ctime_to_ts(struct inode *inode, struct timespec64 ts)
|
|
|
|
{
|
2024-10-02 21:27:21 +00:00
|
|
|
trace_inode_set_ctime_to_ts(inode, &ts);
|
fs: add infrastructure for multigrain timestamps
The VFS has always used coarse-grained timestamps when updating the
ctime and mtime after a change. This has the benefit of allowing
filesystems to optimize away a lot metadata updates, down to around 1
per jiffy, even when a file is under heavy writes.
Unfortunately, this has always been an issue when we're exporting via
NFSv3, which relies on timestamps to validate caches. A lot of changes
can happen in a jiffy, so timestamps aren't sufficient to help the
client decide when to invalidate the cache. Even with NFSv4, a lot of
exported filesystems don't properly support a change attribute and are
subject to the same problems with timestamp granularity. Other
applications have similar issues with timestamps (e.g backup
applications).
If fine-grained timestamps were always used, that would improve the
situation, but that becomes rather expensive, as the underlying
filesystem would have to log a lot more metadata updates.
What is needed is a way to only use fine-grained timestamps when they
are being actively queried. Use the (unused) top bit in
inode->i_ctime_nsec as a flag that indicates whether the current
timestamps have been queried via stat() or the like. When it's set,
allow the update to use a fine-grained timestamp iff it's necessary to
make the ctime show a different value.
If it has been queried, then first see whether the current coarse time
is later than the existing ctime. If it is, accept that value. If it
isn't, then get a fine-grained timestamp and attempt to stamp the inode
ctime with that value. If that races with another concurrent stamp, then
abandon the update and take the new value without retrying.
Filesystems can opt into this by setting the FS_MGTIME fstype flag.
Others should be unaffected (other than being subject to the same floor
value as multigrain filesystems).
Tested-by: Randy Dunlap <rdunlap@infradead.org> # documentation bits
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Link: https://lore.kernel.org/r/20241002-mgtime-v10-3-d1c4717f5284@kernel.org
Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-10-02 21:27:18 +00:00
|
|
|
set_normalized_timespec64(&ts, ts.tv_sec, ts.tv_nsec);
|
|
|
|
inode->i_ctime_sec = ts.tv_sec;
|
|
|
|
inode->i_ctime_nsec = ts.tv_nsec;
|
|
|
|
return ts;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(inode_set_ctime_to_ts);
|
|
|
|
|
2018-01-22 02:04:25 +00:00
|
|
|
/**
|
|
|
|
* timestamp_truncate - Truncate timespec to a granularity
|
|
|
|
* @t: Timespec
|
|
|
|
* @inode: inode being updated
|
|
|
|
*
|
|
|
|
* Truncate a timespec to the granularity supported by the fs
|
|
|
|
* containing the inode. Always rounds down. gran must
|
|
|
|
* not be 0 nor greater than a second (NSEC_PER_SEC, or 10^9 ns).
|
|
|
|
*/
|
|
|
|
struct timespec64 timestamp_truncate(struct timespec64 t, struct inode *inode)
|
|
|
|
{
|
|
|
|
struct super_block *sb = inode->i_sb;
|
|
|
|
unsigned int gran = sb->s_time_gran;
|
|
|
|
|
|
|
|
t.tv_sec = clamp(t.tv_sec, sb->s_time_min, sb->s_time_max);
|
|
|
|
if (unlikely(t.tv_sec == sb->s_time_max || t.tv_sec == sb->s_time_min))
|
|
|
|
t.tv_nsec = 0;
|
|
|
|
|
|
|
|
/* Avoid division in the common cases 1 ns and 1 s. */
|
|
|
|
if (gran == 1)
|
|
|
|
; /* nothing */
|
|
|
|
else if (gran == NSEC_PER_SEC)
|
|
|
|
t.tv_nsec = 0;
|
|
|
|
else if (gran > 1 && gran < NSEC_PER_SEC)
|
|
|
|
t.tv_nsec -= t.tv_nsec % gran;
|
|
|
|
else
|
|
|
|
WARN(1, "invalid file time granularity: %u", gran);
|
|
|
|
return t;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(timestamp_truncate);
|
|
|
|
|
2016-09-14 14:48:02 +00:00
|
|
|
/**
|
fs: add infrastructure for multigrain timestamps
The VFS has always used coarse-grained timestamps when updating the
ctime and mtime after a change. This has the benefit of allowing
filesystems to optimize away a lot metadata updates, down to around 1
per jiffy, even when a file is under heavy writes.
Unfortunately, this has always been an issue when we're exporting via
NFSv3, which relies on timestamps to validate caches. A lot of changes
can happen in a jiffy, so timestamps aren't sufficient to help the
client decide when to invalidate the cache. Even with NFSv4, a lot of
exported filesystems don't properly support a change attribute and are
subject to the same problems with timestamp granularity. Other
applications have similar issues with timestamps (e.g backup
applications).
If fine-grained timestamps were always used, that would improve the
situation, but that becomes rather expensive, as the underlying
filesystem would have to log a lot more metadata updates.
What is needed is a way to only use fine-grained timestamps when they
are being actively queried. Use the (unused) top bit in
inode->i_ctime_nsec as a flag that indicates whether the current
timestamps have been queried via stat() or the like. When it's set,
allow the update to use a fine-grained timestamp iff it's necessary to
make the ctime show a different value.
If it has been queried, then first see whether the current coarse time
is later than the existing ctime. If it is, accept that value. If it
isn't, then get a fine-grained timestamp and attempt to stamp the inode
ctime with that value. If that races with another concurrent stamp, then
abandon the update and take the new value without retrying.
Filesystems can opt into this by setting the FS_MGTIME fstype flag.
Others should be unaffected (other than being subject to the same floor
value as multigrain filesystems).
Tested-by: Randy Dunlap <rdunlap@infradead.org> # documentation bits
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Link: https://lore.kernel.org/r/20241002-mgtime-v10-3-d1c4717f5284@kernel.org
Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-10-02 21:27:18 +00:00
|
|
|
* inode_set_ctime_current - set the ctime to current_time
|
|
|
|
* @inode: inode
|
2016-09-14 14:48:02 +00:00
|
|
|
*
|
fs: add infrastructure for multigrain timestamps
The VFS has always used coarse-grained timestamps when updating the
ctime and mtime after a change. This has the benefit of allowing
filesystems to optimize away a lot metadata updates, down to around 1
per jiffy, even when a file is under heavy writes.
Unfortunately, this has always been an issue when we're exporting via
NFSv3, which relies on timestamps to validate caches. A lot of changes
can happen in a jiffy, so timestamps aren't sufficient to help the
client decide when to invalidate the cache. Even with NFSv4, a lot of
exported filesystems don't properly support a change attribute and are
subject to the same problems with timestamp granularity. Other
applications have similar issues with timestamps (e.g backup
applications).
If fine-grained timestamps were always used, that would improve the
situation, but that becomes rather expensive, as the underlying
filesystem would have to log a lot more metadata updates.
What is needed is a way to only use fine-grained timestamps when they
are being actively queried. Use the (unused) top bit in
inode->i_ctime_nsec as a flag that indicates whether the current
timestamps have been queried via stat() or the like. When it's set,
allow the update to use a fine-grained timestamp iff it's necessary to
make the ctime show a different value.
If it has been queried, then first see whether the current coarse time
is later than the existing ctime. If it is, accept that value. If it
isn't, then get a fine-grained timestamp and attempt to stamp the inode
ctime with that value. If that races with another concurrent stamp, then
abandon the update and take the new value without retrying.
Filesystems can opt into this by setting the FS_MGTIME fstype flag.
Others should be unaffected (other than being subject to the same floor
value as multigrain filesystems).
Tested-by: Randy Dunlap <rdunlap@infradead.org> # documentation bits
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Link: https://lore.kernel.org/r/20241002-mgtime-v10-3-d1c4717f5284@kernel.org
Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-10-02 21:27:18 +00:00
|
|
|
* Set the inode's ctime to the current value for the inode. Returns the
|
|
|
|
* current value that was assigned. If this is not a multigrain inode, then we
|
|
|
|
* set it to the later of the coarse time and floor value.
|
2016-09-14 14:48:02 +00:00
|
|
|
*
|
fs: add infrastructure for multigrain timestamps
The VFS has always used coarse-grained timestamps when updating the
ctime and mtime after a change. This has the benefit of allowing
filesystems to optimize away a lot metadata updates, down to around 1
per jiffy, even when a file is under heavy writes.
Unfortunately, this has always been an issue when we're exporting via
NFSv3, which relies on timestamps to validate caches. A lot of changes
can happen in a jiffy, so timestamps aren't sufficient to help the
client decide when to invalidate the cache. Even with NFSv4, a lot of
exported filesystems don't properly support a change attribute and are
subject to the same problems with timestamp granularity. Other
applications have similar issues with timestamps (e.g backup
applications).
If fine-grained timestamps were always used, that would improve the
situation, but that becomes rather expensive, as the underlying
filesystem would have to log a lot more metadata updates.
What is needed is a way to only use fine-grained timestamps when they
are being actively queried. Use the (unused) top bit in
inode->i_ctime_nsec as a flag that indicates whether the current
timestamps have been queried via stat() or the like. When it's set,
allow the update to use a fine-grained timestamp iff it's necessary to
make the ctime show a different value.
If it has been queried, then first see whether the current coarse time
is later than the existing ctime. If it is, accept that value. If it
isn't, then get a fine-grained timestamp and attempt to stamp the inode
ctime with that value. If that races with another concurrent stamp, then
abandon the update and take the new value without retrying.
Filesystems can opt into this by setting the FS_MGTIME fstype flag.
Others should be unaffected (other than being subject to the same floor
value as multigrain filesystems).
Tested-by: Randy Dunlap <rdunlap@infradead.org> # documentation bits
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Link: https://lore.kernel.org/r/20241002-mgtime-v10-3-d1c4717f5284@kernel.org
Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-10-02 21:27:18 +00:00
|
|
|
* If it is multigrain, then we first see if the coarse-grained timestamp is
|
|
|
|
* distinct from what is already there. If so, then use that. Otherwise, get a
|
|
|
|
* fine-grained timestamp.
|
|
|
|
*
|
|
|
|
* After that, try to swap the new value into i_ctime_nsec. Accept the
|
|
|
|
* resulting ctime, regardless of the outcome of the swap. If it has
|
|
|
|
* already been replaced, then that timestamp is later than the earlier
|
|
|
|
* unacceptable one, and is thus acceptable.
|
2016-09-14 14:48:02 +00:00
|
|
|
*/
|
fs: add infrastructure for multigrain timestamps
The VFS has always used coarse-grained timestamps when updating the
ctime and mtime after a change. This has the benefit of allowing
filesystems to optimize away a lot metadata updates, down to around 1
per jiffy, even when a file is under heavy writes.
Unfortunately, this has always been an issue when we're exporting via
NFSv3, which relies on timestamps to validate caches. A lot of changes
can happen in a jiffy, so timestamps aren't sufficient to help the
client decide when to invalidate the cache. Even with NFSv4, a lot of
exported filesystems don't properly support a change attribute and are
subject to the same problems with timestamp granularity. Other
applications have similar issues with timestamps (e.g backup
applications).
If fine-grained timestamps were always used, that would improve the
situation, but that becomes rather expensive, as the underlying
filesystem would have to log a lot more metadata updates.
What is needed is a way to only use fine-grained timestamps when they
are being actively queried. Use the (unused) top bit in
inode->i_ctime_nsec as a flag that indicates whether the current
timestamps have been queried via stat() or the like. When it's set,
allow the update to use a fine-grained timestamp iff it's necessary to
make the ctime show a different value.
If it has been queried, then first see whether the current coarse time
is later than the existing ctime. If it is, accept that value. If it
isn't, then get a fine-grained timestamp and attempt to stamp the inode
ctime with that value. If that races with another concurrent stamp, then
abandon the update and take the new value without retrying.
Filesystems can opt into this by setting the FS_MGTIME fstype flag.
Others should be unaffected (other than being subject to the same floor
value as multigrain filesystems).
Tested-by: Randy Dunlap <rdunlap@infradead.org> # documentation bits
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Link: https://lore.kernel.org/r/20241002-mgtime-v10-3-d1c4717f5284@kernel.org
Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-10-02 21:27:18 +00:00
|
|
|
struct timespec64 inode_set_ctime_current(struct inode *inode)
|
2016-09-14 14:48:02 +00:00
|
|
|
{
|
vfs: replace current_kernel_time64 with ktime equivalent
current_time is the last remaining caller of current_kernel_time64(),
which is a wrapper around ktime_get_coarse_real_ts64(). This calls the
latter directly for consistency with the rest of the kernel that is moving
to the ktime_get_ family of time accessors, as now documented in
Documentation/core-api/timekeeping.rst.
An open questions is whether we may want to actually call the more
accurate ktime_get_real_ts64() for file systems that save high-resolution
timestamps in their on-disk format. This would add a small overhead to
each update of the inode stamps but lead to inode timestamps to actually
have a usable resolution better than one jiffy (1 to 10 milliseconds
normally). Experiments on a variety of hardware platforms show a typical
time of around 100 CPU cycles to read the cycle counter and calculate the
accurate time from that. On old platforms without a cycle counter, this
can be signiciantly higher, up to several microseconds to access a
hardware clock, but those have become very rare by now.
I traced the original addition of the current_kernel_time() call to set
the nanosecond fields back to linux-2.5.48, where Andi Kleen added a patch
with subject "nanosecond stat timefields". Andi explains that the
motivation was to introduce as little overhead as possible back then. At
this time, reading the clock hardware was also more expensive when most
architectures did not have a cycle counter.
One side effect of having more accurate inode timestamp would be having to
write out the inode every time that mtime/ctime/atime get touched on most
systems, whereas many file systems today only write it when the timestamps
have changed, i.e. at most once per jiffy unless something else changes
as well. That change would certainly be noticed in some workloads, which
is enough reason to not do it without a good reason, regardless of the
cost of reading the time.
One thing we could still consider however would be to round the timestamps
from current_time() to multiples of NSEC_PER_JIFFY, e.g. full
milliseconds rather than having six or seven meaningless but confusing
digits at the end of the timestamp.
Link: http://lkml.kernel.org/r/20180726130820.4174359-1-arnd@arndb.de
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2018-12-05 00:14:27 +00:00
|
|
|
struct timespec64 now;
|
fs: add infrastructure for multigrain timestamps
The VFS has always used coarse-grained timestamps when updating the
ctime and mtime after a change. This has the benefit of allowing
filesystems to optimize away a lot metadata updates, down to around 1
per jiffy, even when a file is under heavy writes.
Unfortunately, this has always been an issue when we're exporting via
NFSv3, which relies on timestamps to validate caches. A lot of changes
can happen in a jiffy, so timestamps aren't sufficient to help the
client decide when to invalidate the cache. Even with NFSv4, a lot of
exported filesystems don't properly support a change attribute and are
subject to the same problems with timestamp granularity. Other
applications have similar issues with timestamps (e.g backup
applications).
If fine-grained timestamps were always used, that would improve the
situation, but that becomes rather expensive, as the underlying
filesystem would have to log a lot more metadata updates.
What is needed is a way to only use fine-grained timestamps when they
are being actively queried. Use the (unused) top bit in
inode->i_ctime_nsec as a flag that indicates whether the current
timestamps have been queried via stat() or the like. When it's set,
allow the update to use a fine-grained timestamp iff it's necessary to
make the ctime show a different value.
If it has been queried, then first see whether the current coarse time
is later than the existing ctime. If it is, accept that value. If it
isn't, then get a fine-grained timestamp and attempt to stamp the inode
ctime with that value. If that races with another concurrent stamp, then
abandon the update and take the new value without retrying.
Filesystems can opt into this by setting the FS_MGTIME fstype flag.
Others should be unaffected (other than being subject to the same floor
value as multigrain filesystems).
Tested-by: Randy Dunlap <rdunlap@infradead.org> # documentation bits
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Link: https://lore.kernel.org/r/20241002-mgtime-v10-3-d1c4717f5284@kernel.org
Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-10-02 21:27:18 +00:00
|
|
|
u32 cns, cur;
|
vfs: replace current_kernel_time64 with ktime equivalent
current_time is the last remaining caller of current_kernel_time64(),
which is a wrapper around ktime_get_coarse_real_ts64(). This calls the
latter directly for consistency with the rest of the kernel that is moving
to the ktime_get_ family of time accessors, as now documented in
Documentation/core-api/timekeeping.rst.
An open questions is whether we may want to actually call the more
accurate ktime_get_real_ts64() for file systems that save high-resolution
timestamps in their on-disk format. This would add a small overhead to
each update of the inode stamps but lead to inode timestamps to actually
have a usable resolution better than one jiffy (1 to 10 milliseconds
normally). Experiments on a variety of hardware platforms show a typical
time of around 100 CPU cycles to read the cycle counter and calculate the
accurate time from that. On old platforms without a cycle counter, this
can be signiciantly higher, up to several microseconds to access a
hardware clock, but those have become very rare by now.
I traced the original addition of the current_kernel_time() call to set
the nanosecond fields back to linux-2.5.48, where Andi Kleen added a patch
with subject "nanosecond stat timefields". Andi explains that the
motivation was to introduce as little overhead as possible back then. At
this time, reading the clock hardware was also more expensive when most
architectures did not have a cycle counter.
One side effect of having more accurate inode timestamp would be having to
write out the inode every time that mtime/ctime/atime get touched on most
systems, whereas many file systems today only write it when the timestamps
have changed, i.e. at most once per jiffy unless something else changes
as well. That change would certainly be noticed in some workloads, which
is enough reason to not do it without a good reason, regardless of the
cost of reading the time.
One thing we could still consider however would be to round the timestamps
from current_time() to multiples of NSEC_PER_JIFFY, e.g. full
milliseconds rather than having six or seven meaningless but confusing
digits at the end of the timestamp.
Link: http://lkml.kernel.org/r/20180726130820.4174359-1-arnd@arndb.de
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2018-12-05 00:14:27 +00:00
|
|
|
|
fs: add infrastructure for multigrain timestamps
The VFS has always used coarse-grained timestamps when updating the
ctime and mtime after a change. This has the benefit of allowing
filesystems to optimize away a lot metadata updates, down to around 1
per jiffy, even when a file is under heavy writes.
Unfortunately, this has always been an issue when we're exporting via
NFSv3, which relies on timestamps to validate caches. A lot of changes
can happen in a jiffy, so timestamps aren't sufficient to help the
client decide when to invalidate the cache. Even with NFSv4, a lot of
exported filesystems don't properly support a change attribute and are
subject to the same problems with timestamp granularity. Other
applications have similar issues with timestamps (e.g backup
applications).
If fine-grained timestamps were always used, that would improve the
situation, but that becomes rather expensive, as the underlying
filesystem would have to log a lot more metadata updates.
What is needed is a way to only use fine-grained timestamps when they
are being actively queried. Use the (unused) top bit in
inode->i_ctime_nsec as a flag that indicates whether the current
timestamps have been queried via stat() or the like. When it's set,
allow the update to use a fine-grained timestamp iff it's necessary to
make the ctime show a different value.
If it has been queried, then first see whether the current coarse time
is later than the existing ctime. If it is, accept that value. If it
isn't, then get a fine-grained timestamp and attempt to stamp the inode
ctime with that value. If that races with another concurrent stamp, then
abandon the update and take the new value without retrying.
Filesystems can opt into this by setting the FS_MGTIME fstype flag.
Others should be unaffected (other than being subject to the same floor
value as multigrain filesystems).
Tested-by: Randy Dunlap <rdunlap@infradead.org> # documentation bits
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Link: https://lore.kernel.org/r/20241002-mgtime-v10-3-d1c4717f5284@kernel.org
Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-10-02 21:27:18 +00:00
|
|
|
ktime_get_coarse_real_ts64_mg(&now);
|
|
|
|
now = timestamp_truncate(now, inode);
|
2016-09-14 14:48:02 +00:00
|
|
|
|
fs: add infrastructure for multigrain timestamps
The VFS has always used coarse-grained timestamps when updating the
ctime and mtime after a change. This has the benefit of allowing
filesystems to optimize away a lot metadata updates, down to around 1
per jiffy, even when a file is under heavy writes.
Unfortunately, this has always been an issue when we're exporting via
NFSv3, which relies on timestamps to validate caches. A lot of changes
can happen in a jiffy, so timestamps aren't sufficient to help the
client decide when to invalidate the cache. Even with NFSv4, a lot of
exported filesystems don't properly support a change attribute and are
subject to the same problems with timestamp granularity. Other
applications have similar issues with timestamps (e.g backup
applications).
If fine-grained timestamps were always used, that would improve the
situation, but that becomes rather expensive, as the underlying
filesystem would have to log a lot more metadata updates.
What is needed is a way to only use fine-grained timestamps when they
are being actively queried. Use the (unused) top bit in
inode->i_ctime_nsec as a flag that indicates whether the current
timestamps have been queried via stat() or the like. When it's set,
allow the update to use a fine-grained timestamp iff it's necessary to
make the ctime show a different value.
If it has been queried, then first see whether the current coarse time
is later than the existing ctime. If it is, accept that value. If it
isn't, then get a fine-grained timestamp and attempt to stamp the inode
ctime with that value. If that races with another concurrent stamp, then
abandon the update and take the new value without retrying.
Filesystems can opt into this by setting the FS_MGTIME fstype flag.
Others should be unaffected (other than being subject to the same floor
value as multigrain filesystems).
Tested-by: Randy Dunlap <rdunlap@infradead.org> # documentation bits
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Link: https://lore.kernel.org/r/20241002-mgtime-v10-3-d1c4717f5284@kernel.org
Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-10-02 21:27:18 +00:00
|
|
|
/* Just return that if this is not a multigrain fs */
|
|
|
|
if (!is_mgtime(inode)) {
|
|
|
|
inode_set_ctime_to_ts(inode, now);
|
|
|
|
goto out;
|
|
|
|
}
|
2023-07-05 18:58:10 +00:00
|
|
|
|
fs: add infrastructure for multigrain timestamps
The VFS has always used coarse-grained timestamps when updating the
ctime and mtime after a change. This has the benefit of allowing
filesystems to optimize away a lot metadata updates, down to around 1
per jiffy, even when a file is under heavy writes.
Unfortunately, this has always been an issue when we're exporting via
NFSv3, which relies on timestamps to validate caches. A lot of changes
can happen in a jiffy, so timestamps aren't sufficient to help the
client decide when to invalidate the cache. Even with NFSv4, a lot of
exported filesystems don't properly support a change attribute and are
subject to the same problems with timestamp granularity. Other
applications have similar issues with timestamps (e.g backup
applications).
If fine-grained timestamps were always used, that would improve the
situation, but that becomes rather expensive, as the underlying
filesystem would have to log a lot more metadata updates.
What is needed is a way to only use fine-grained timestamps when they
are being actively queried. Use the (unused) top bit in
inode->i_ctime_nsec as a flag that indicates whether the current
timestamps have been queried via stat() or the like. When it's set,
allow the update to use a fine-grained timestamp iff it's necessary to
make the ctime show a different value.
If it has been queried, then first see whether the current coarse time
is later than the existing ctime. If it is, accept that value. If it
isn't, then get a fine-grained timestamp and attempt to stamp the inode
ctime with that value. If that races with another concurrent stamp, then
abandon the update and take the new value without retrying.
Filesystems can opt into this by setting the FS_MGTIME fstype flag.
Others should be unaffected (other than being subject to the same floor
value as multigrain filesystems).
Tested-by: Randy Dunlap <rdunlap@infradead.org> # documentation bits
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Link: https://lore.kernel.org/r/20241002-mgtime-v10-3-d1c4717f5284@kernel.org
Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-10-02 21:27:18 +00:00
|
|
|
/*
|
|
|
|
* A fine-grained time is only needed if someone has queried
|
|
|
|
* for timestamps, and the current coarse grained time isn't
|
|
|
|
* later than what's already there.
|
|
|
|
*/
|
|
|
|
cns = smp_load_acquire(&inode->i_ctime_nsec);
|
|
|
|
if (cns & I_CTIME_QUERIED) {
|
|
|
|
struct timespec64 ctime = { .tv_sec = inode->i_ctime_sec,
|
|
|
|
.tv_nsec = cns & ~I_CTIME_QUERIED };
|
|
|
|
|
|
|
|
if (timespec64_compare(&now, &ctime) <= 0) {
|
|
|
|
ktime_get_real_ts64_mg(&now);
|
|
|
|
now = timestamp_truncate(now, inode);
|
2024-10-02 21:27:22 +00:00
|
|
|
mgtime_counter_inc(mg_fine_stamps);
|
fs: add infrastructure for multigrain timestamps
The VFS has always used coarse-grained timestamps when updating the
ctime and mtime after a change. This has the benefit of allowing
filesystems to optimize away a lot metadata updates, down to around 1
per jiffy, even when a file is under heavy writes.
Unfortunately, this has always been an issue when we're exporting via
NFSv3, which relies on timestamps to validate caches. A lot of changes
can happen in a jiffy, so timestamps aren't sufficient to help the
client decide when to invalidate the cache. Even with NFSv4, a lot of
exported filesystems don't properly support a change attribute and are
subject to the same problems with timestamp granularity. Other
applications have similar issues with timestamps (e.g backup
applications).
If fine-grained timestamps were always used, that would improve the
situation, but that becomes rather expensive, as the underlying
filesystem would have to log a lot more metadata updates.
What is needed is a way to only use fine-grained timestamps when they
are being actively queried. Use the (unused) top bit in
inode->i_ctime_nsec as a flag that indicates whether the current
timestamps have been queried via stat() or the like. When it's set,
allow the update to use a fine-grained timestamp iff it's necessary to
make the ctime show a different value.
If it has been queried, then first see whether the current coarse time
is later than the existing ctime. If it is, accept that value. If it
isn't, then get a fine-grained timestamp and attempt to stamp the inode
ctime with that value. If that races with another concurrent stamp, then
abandon the update and take the new value without retrying.
Filesystems can opt into this by setting the FS_MGTIME fstype flag.
Others should be unaffected (other than being subject to the same floor
value as multigrain filesystems).
Tested-by: Randy Dunlap <rdunlap@infradead.org> # documentation bits
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Link: https://lore.kernel.org/r/20241002-mgtime-v10-3-d1c4717f5284@kernel.org
Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-10-02 21:27:18 +00:00
|
|
|
}
|
|
|
|
}
|
2024-10-02 21:27:22 +00:00
|
|
|
mgtime_counter_inc(mg_ctime_updates);
|
fs: add infrastructure for multigrain timestamps
The VFS has always used coarse-grained timestamps when updating the
ctime and mtime after a change. This has the benefit of allowing
filesystems to optimize away a lot metadata updates, down to around 1
per jiffy, even when a file is under heavy writes.
Unfortunately, this has always been an issue when we're exporting via
NFSv3, which relies on timestamps to validate caches. A lot of changes
can happen in a jiffy, so timestamps aren't sufficient to help the
client decide when to invalidate the cache. Even with NFSv4, a lot of
exported filesystems don't properly support a change attribute and are
subject to the same problems with timestamp granularity. Other
applications have similar issues with timestamps (e.g backup
applications).
If fine-grained timestamps were always used, that would improve the
situation, but that becomes rather expensive, as the underlying
filesystem would have to log a lot more metadata updates.
What is needed is a way to only use fine-grained timestamps when they
are being actively queried. Use the (unused) top bit in
inode->i_ctime_nsec as a flag that indicates whether the current
timestamps have been queried via stat() or the like. When it's set,
allow the update to use a fine-grained timestamp iff it's necessary to
make the ctime show a different value.
If it has been queried, then first see whether the current coarse time
is later than the existing ctime. If it is, accept that value. If it
isn't, then get a fine-grained timestamp and attempt to stamp the inode
ctime with that value. If that races with another concurrent stamp, then
abandon the update and take the new value without retrying.
Filesystems can opt into this by setting the FS_MGTIME fstype flag.
Others should be unaffected (other than being subject to the same floor
value as multigrain filesystems).
Tested-by: Randy Dunlap <rdunlap@infradead.org> # documentation bits
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Link: https://lore.kernel.org/r/20241002-mgtime-v10-3-d1c4717f5284@kernel.org
Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-10-02 21:27:18 +00:00
|
|
|
|
|
|
|
/* No need to cmpxchg if it's exactly the same */
|
2024-10-02 21:27:21 +00:00
|
|
|
if (cns == now.tv_nsec && inode->i_ctime_sec == now.tv_sec) {
|
|
|
|
trace_ctime_xchg_skip(inode, &now);
|
fs: add infrastructure for multigrain timestamps
The VFS has always used coarse-grained timestamps when updating the
ctime and mtime after a change. This has the benefit of allowing
filesystems to optimize away a lot metadata updates, down to around 1
per jiffy, even when a file is under heavy writes.
Unfortunately, this has always been an issue when we're exporting via
NFSv3, which relies on timestamps to validate caches. A lot of changes
can happen in a jiffy, so timestamps aren't sufficient to help the
client decide when to invalidate the cache. Even with NFSv4, a lot of
exported filesystems don't properly support a change attribute and are
subject to the same problems with timestamp granularity. Other
applications have similar issues with timestamps (e.g backup
applications).
If fine-grained timestamps were always used, that would improve the
situation, but that becomes rather expensive, as the underlying
filesystem would have to log a lot more metadata updates.
What is needed is a way to only use fine-grained timestamps when they
are being actively queried. Use the (unused) top bit in
inode->i_ctime_nsec as a flag that indicates whether the current
timestamps have been queried via stat() or the like. When it's set,
allow the update to use a fine-grained timestamp iff it's necessary to
make the ctime show a different value.
If it has been queried, then first see whether the current coarse time
is later than the existing ctime. If it is, accept that value. If it
isn't, then get a fine-grained timestamp and attempt to stamp the inode
ctime with that value. If that races with another concurrent stamp, then
abandon the update and take the new value without retrying.
Filesystems can opt into this by setting the FS_MGTIME fstype flag.
Others should be unaffected (other than being subject to the same floor
value as multigrain filesystems).
Tested-by: Randy Dunlap <rdunlap@infradead.org> # documentation bits
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Link: https://lore.kernel.org/r/20241002-mgtime-v10-3-d1c4717f5284@kernel.org
Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-10-02 21:27:18 +00:00
|
|
|
goto out;
|
2024-10-02 21:27:21 +00:00
|
|
|
}
|
fs: add infrastructure for multigrain timestamps
The VFS has always used coarse-grained timestamps when updating the
ctime and mtime after a change. This has the benefit of allowing
filesystems to optimize away a lot metadata updates, down to around 1
per jiffy, even when a file is under heavy writes.
Unfortunately, this has always been an issue when we're exporting via
NFSv3, which relies on timestamps to validate caches. A lot of changes
can happen in a jiffy, so timestamps aren't sufficient to help the
client decide when to invalidate the cache. Even with NFSv4, a lot of
exported filesystems don't properly support a change attribute and are
subject to the same problems with timestamp granularity. Other
applications have similar issues with timestamps (e.g backup
applications).
If fine-grained timestamps were always used, that would improve the
situation, but that becomes rather expensive, as the underlying
filesystem would have to log a lot more metadata updates.
What is needed is a way to only use fine-grained timestamps when they
are being actively queried. Use the (unused) top bit in
inode->i_ctime_nsec as a flag that indicates whether the current
timestamps have been queried via stat() or the like. When it's set,
allow the update to use a fine-grained timestamp iff it's necessary to
make the ctime show a different value.
If it has been queried, then first see whether the current coarse time
is later than the existing ctime. If it is, accept that value. If it
isn't, then get a fine-grained timestamp and attempt to stamp the inode
ctime with that value. If that races with another concurrent stamp, then
abandon the update and take the new value without retrying.
Filesystems can opt into this by setting the FS_MGTIME fstype flag.
Others should be unaffected (other than being subject to the same floor
value as multigrain filesystems).
Tested-by: Randy Dunlap <rdunlap@infradead.org> # documentation bits
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Link: https://lore.kernel.org/r/20241002-mgtime-v10-3-d1c4717f5284@kernel.org
Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-10-02 21:27:18 +00:00
|
|
|
cur = cns;
|
|
|
|
retry:
|
|
|
|
/* Try to swap the nsec value into place. */
|
|
|
|
if (try_cmpxchg(&inode->i_ctime_nsec, &cur, now.tv_nsec)) {
|
|
|
|
/* If swap occurred, then we're (mostly) done */
|
|
|
|
inode->i_ctime_sec = now.tv_sec;
|
2024-10-02 21:27:21 +00:00
|
|
|
trace_ctime_ns_xchg(inode, cns, now.tv_nsec, cur);
|
2024-10-02 21:27:22 +00:00
|
|
|
mgtime_counter_inc(mg_ctime_swaps);
|
fs: add infrastructure for multigrain timestamps
The VFS has always used coarse-grained timestamps when updating the
ctime and mtime after a change. This has the benefit of allowing
filesystems to optimize away a lot metadata updates, down to around 1
per jiffy, even when a file is under heavy writes.
Unfortunately, this has always been an issue when we're exporting via
NFSv3, which relies on timestamps to validate caches. A lot of changes
can happen in a jiffy, so timestamps aren't sufficient to help the
client decide when to invalidate the cache. Even with NFSv4, a lot of
exported filesystems don't properly support a change attribute and are
subject to the same problems with timestamp granularity. Other
applications have similar issues with timestamps (e.g backup
applications).
If fine-grained timestamps were always used, that would improve the
situation, but that becomes rather expensive, as the underlying
filesystem would have to log a lot more metadata updates.
What is needed is a way to only use fine-grained timestamps when they
are being actively queried. Use the (unused) top bit in
inode->i_ctime_nsec as a flag that indicates whether the current
timestamps have been queried via stat() or the like. When it's set,
allow the update to use a fine-grained timestamp iff it's necessary to
make the ctime show a different value.
If it has been queried, then first see whether the current coarse time
is later than the existing ctime. If it is, accept that value. If it
isn't, then get a fine-grained timestamp and attempt to stamp the inode
ctime with that value. If that races with another concurrent stamp, then
abandon the update and take the new value without retrying.
Filesystems can opt into this by setting the FS_MGTIME fstype flag.
Others should be unaffected (other than being subject to the same floor
value as multigrain filesystems).
Tested-by: Randy Dunlap <rdunlap@infradead.org> # documentation bits
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Link: https://lore.kernel.org/r/20241002-mgtime-v10-3-d1c4717f5284@kernel.org
Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-10-02 21:27:18 +00:00
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* Was the change due to someone marking the old ctime QUERIED?
|
|
|
|
* If so then retry the swap. This can only happen once since
|
|
|
|
* the only way to clear I_CTIME_QUERIED is to stamp the inode
|
|
|
|
* with a new ctime.
|
|
|
|
*/
|
|
|
|
if (!(cns & I_CTIME_QUERIED) && (cns | I_CTIME_QUERIED) == cur) {
|
|
|
|
cns = cur;
|
|
|
|
goto retry;
|
|
|
|
}
|
|
|
|
/* Otherwise, keep the existing ctime */
|
|
|
|
now.tv_sec = inode->i_ctime_sec;
|
|
|
|
now.tv_nsec = cur & ~I_CTIME_QUERIED;
|
|
|
|
}
|
|
|
|
out:
|
2023-07-05 18:58:10 +00:00
|
|
|
return now;
|
2016-09-14 14:48:02 +00:00
|
|
|
}
|
2023-07-05 18:58:10 +00:00
|
|
|
EXPORT_SYMBOL(inode_set_ctime_current);
|
2016-09-14 14:48:02 +00:00
|
|
|
|
2023-07-05 18:58:10 +00:00
|
|
|
/**
|
2024-10-02 21:27:20 +00:00
|
|
|
* inode_set_ctime_deleg - try to update the ctime on a delegated inode
|
|
|
|
* @inode: inode to update
|
|
|
|
* @update: timespec64 to set the ctime
|
2023-07-05 18:58:10 +00:00
|
|
|
*
|
2024-10-02 21:27:20 +00:00
|
|
|
* Attempt to atomically update the ctime on behalf of a delegation holder.
|
|
|
|
*
|
|
|
|
* The nfs server can call back the holder of a delegation to get updated
|
|
|
|
* inode attributes, including the mtime. When updating the mtime, update
|
|
|
|
* the ctime to a value at least equal to that.
|
|
|
|
*
|
|
|
|
* This can race with concurrent updates to the inode, in which
|
|
|
|
* case the update is skipped.
|
|
|
|
*
|
|
|
|
* Note that this works even when multigrain timestamps are not enabled,
|
|
|
|
* so it is used in either case.
|
2023-07-05 18:58:10 +00:00
|
|
|
*/
|
2024-10-02 21:27:20 +00:00
|
|
|
struct timespec64 inode_set_ctime_deleg(struct inode *inode, struct timespec64 update)
|
2023-07-05 18:58:10 +00:00
|
|
|
{
|
2024-10-02 21:27:20 +00:00
|
|
|
struct timespec64 now, cur_ts;
|
|
|
|
u32 cur, old;
|
2023-07-05 18:58:10 +00:00
|
|
|
|
2024-10-02 21:27:20 +00:00
|
|
|
/* pairs with try_cmpxchg below */
|
|
|
|
cur = smp_load_acquire(&inode->i_ctime_nsec);
|
|
|
|
cur_ts.tv_nsec = cur & ~I_CTIME_QUERIED;
|
|
|
|
cur_ts.tv_sec = inode->i_ctime_sec;
|
|
|
|
|
|
|
|
/* If the update is older than the existing value, skip it. */
|
|
|
|
if (timespec64_compare(&update, &cur_ts) <= 0)
|
|
|
|
return cur_ts;
|
|
|
|
|
|
|
|
ktime_get_coarse_real_ts64_mg(&now);
|
|
|
|
|
|
|
|
/* Clamp the update to "now" if it's in the future */
|
|
|
|
if (timespec64_compare(&update, &now) > 0)
|
|
|
|
update = now;
|
|
|
|
|
|
|
|
update = timestamp_truncate(update, inode);
|
|
|
|
|
|
|
|
/* No need to update if the values are already the same */
|
|
|
|
if (timespec64_equal(&update, &cur_ts))
|
|
|
|
return cur_ts;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Try to swap the nsec value into place. If it fails, that means
|
|
|
|
* it raced with an update due to a write or similar activity. That
|
|
|
|
* stamp takes precedence, so just skip the update.
|
|
|
|
*/
|
|
|
|
retry:
|
|
|
|
old = cur;
|
|
|
|
if (try_cmpxchg(&inode->i_ctime_nsec, &cur, update.tv_nsec)) {
|
|
|
|
inode->i_ctime_sec = update.tv_sec;
|
|
|
|
mgtime_counter_inc(mg_ctime_swaps);
|
|
|
|
return update;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Was the change due to another task marking the old ctime QUERIED?
|
|
|
|
*
|
|
|
|
* If so, then retry the swap. This can only happen once since
|
|
|
|
* the only way to clear I_CTIME_QUERIED is to stamp the inode
|
|
|
|
* with a new ctime.
|
|
|
|
*/
|
|
|
|
if (!(old & I_CTIME_QUERIED) && (cur == (old | I_CTIME_QUERIED)))
|
|
|
|
goto retry;
|
|
|
|
|
|
|
|
/* Otherwise, it was a new timestamp. */
|
|
|
|
cur_ts.tv_sec = inode->i_ctime_sec;
|
|
|
|
cur_ts.tv_nsec = cur & ~I_CTIME_QUERIED;
|
|
|
|
return cur_ts;
|
2016-09-14 14:48:02 +00:00
|
|
|
}
|
2024-10-02 21:27:20 +00:00
|
|
|
EXPORT_SYMBOL(inode_set_ctime_deleg);
|
2022-07-14 06:11:25 +00:00
|
|
|
|
2022-10-17 15:06:34 +00:00
|
|
|
/**
|
|
|
|
* in_group_or_capable - check whether caller is CAP_FSETID privileged
|
2023-01-13 11:49:27 +00:00
|
|
|
* @idmap: idmap of the mount @inode was found from
|
2022-10-17 15:06:34 +00:00
|
|
|
* @inode: inode to check
|
|
|
|
* @vfsgid: the new/current vfsgid of @inode
|
|
|
|
*
|
2024-10-08 12:16:02 +00:00
|
|
|
* Check whether @vfsgid is in the caller's group list or if the caller is
|
2022-10-17 15:06:34 +00:00
|
|
|
* privileged with CAP_FSETID over @inode. This can be used to determine
|
|
|
|
* whether the setgid bit can be kept or must be dropped.
|
|
|
|
*
|
|
|
|
* Return: true if the caller is sufficiently privileged, false if not.
|
|
|
|
*/
|
2023-01-13 11:49:27 +00:00
|
|
|
bool in_group_or_capable(struct mnt_idmap *idmap,
|
2022-10-17 15:06:34 +00:00
|
|
|
const struct inode *inode, vfsgid_t vfsgid)
|
|
|
|
{
|
|
|
|
if (vfsgid_in_group_p(vfsgid))
|
|
|
|
return true;
|
2023-01-13 11:49:27 +00:00
|
|
|
if (capable_wrt_inode_uidgid(idmap, inode, CAP_FSETID))
|
2022-10-17 15:06:34 +00:00
|
|
|
return true;
|
|
|
|
return false;
|
|
|
|
}
|
2024-06-20 03:23:33 +00:00
|
|
|
EXPORT_SYMBOL(in_group_or_capable);
|
2022-10-17 15:06:34 +00:00
|
|
|
|
2022-07-14 06:11:25 +00:00
|
|
|
/**
|
|
|
|
* mode_strip_sgid - handle the sgid bit for non-directories
|
2023-01-13 11:49:27 +00:00
|
|
|
* @idmap: idmap of the mount the inode was created from
|
2022-07-14 06:11:25 +00:00
|
|
|
* @dir: parent directory inode
|
|
|
|
* @mode: mode of the file to be created in @dir
|
|
|
|
*
|
|
|
|
* If the @mode of the new file has both the S_ISGID and S_IXGRP bit
|
|
|
|
* raised and @dir has the S_ISGID bit raised ensure that the caller is
|
|
|
|
* either in the group of the parent directory or they have CAP_FSETID
|
|
|
|
* in their user namespace and are privileged over the parent directory.
|
|
|
|
* In all other cases, strip the S_ISGID bit from @mode.
|
|
|
|
*
|
|
|
|
* Return: the new mode to use for the file
|
|
|
|
*/
|
2023-01-13 11:49:27 +00:00
|
|
|
umode_t mode_strip_sgid(struct mnt_idmap *idmap,
|
2022-07-14 06:11:25 +00:00
|
|
|
const struct inode *dir, umode_t mode)
|
|
|
|
{
|
|
|
|
if ((mode & (S_ISGID | S_IXGRP)) != (S_ISGID | S_IXGRP))
|
|
|
|
return mode;
|
|
|
|
if (S_ISDIR(mode) || !dir || !(dir->i_mode & S_ISGID))
|
|
|
|
return mode;
|
2023-01-13 11:49:30 +00:00
|
|
|
if (in_group_or_capable(idmap, dir, i_gid_into_vfsgid(idmap, dir)))
|
2022-07-14 06:11:25 +00:00
|
|
|
return mode;
|
|
|
|
return mode & ~S_ISGID;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(mode_strip_sgid);
|