- 30 Jul, 2022 36 commits
-
-
Chuck Lever authored
These tracepoints collect different information: the create case does not open a file, so there's no nf_file available. Reviewed-by:
Jeff Layton <jlayton@kernel.org> Signed-off-by:
Chuck Lever <chuck.lever@oracle.com>
-
Chuck Lever authored
Reviewed-by:
-
Chuck Lever authored
Enable the filecache hash table to start small, then grow with the workload. Smaller server deployments benefit because there should be lower memory utilization. Larger server deployments should see improved scaling with the number of open files. Suggested-by:
Dave Chinner <david@fromorbit.com> Reviewed-by:
-
Chuck Lever authored
Add code to initialize and tear down an rhashtable. The rhashtable is not used yet. Reviewed-by:
-
Chuck Lever authored
In a moment, the nfsd_file_hashtbl global will be replaced with an rhashtable. Replace the one or two spots that need to check if the hash table is available. We can easily reuse the SHUTDOWN flag for this purpose. Document that this mechanism relies on callers to hold the nfsd_mutex to prevent init, shutdown, and purging to run concurrently. Reviewed-by:
-
Chuck Lever authored
The value in this field can always be computed from nf_inode, thus it is no longer used. Reviewed-by:
-
Chuck Lever authored
Remove an unnecessary use of nf_hashval. Reviewed-by:
-
Chuck Lever authored
The code that computes the hashval is the same in both callers. To prevent them from going stale, reframe the documenting comments to remove descriptions of the underlying hash table structure, which is about to be replaced. Reviewed-by:
-
Chuck Lever authored
Remove an unnecessary usage of nf_hashval. Reviewed-by:
-
Chuck Lever authored
IIUC, holding the hash bucket lock is needed only in nfsd_file_unhash, and there is already a lockdep assertion there. Reviewed-by:
-
Chuck Lever authored
I'm about to replace nfsd_file_hashtbl with an rhashtable. The individual hash values will no longer be visible or relevant, so remove them from the tracepoints. Reviewed-by:
-
Chuck Lever authored
The checks in nfsd_file_acquire() and nfsd_file_put() that directly invoke filecache garbage collection are intended to keep cache occupancy between a low- and high-watermark. The reason to limit the capacity of the filecache is to keep filecache lookups reasonably fast. However, invoking garbage collection at those points has some undesirable negative impacts. Files that are held open by NFSv4 clients often push the occupancy of the filecache over these watermarks. At that point: - Every call to nfsd_file_acquire() and nfsd_file_put() results in an LRU walk. This has the same effect on lookup latency as long chains in the hash table. - Garbage collection will then run on every nfsd thread, causing a lot of unnecessary lock contention. - Limiting cache capacity pushes out files used only by NFSv3 clients, which are the type of files the filecache is supposed to help. To address those negative impacts, remove the direct calls to the garbage collector. Subsequent patches will address maintaining lookup efficiency as cache capacity increases. Suggested-by:
Wang Yugui <wangyugui@e16-tech.com> Suggested-by:
-
Chuck Lever authored
Without LRU item rotation, the shrinker visits only a few items on the end of the LRU list, and those would always be long-term OPEN files for NFSv4 workloads. That makes the filecache shrinker completely ineffective. Adopt the same strategy as the inode LRU by using LRU_ROTATE. Suggested-by:
-
Chuck Lever authored
There have been reports of problems when running fstests generic/531 against Linux NFS servers with NFSv4. The NFS server that hosts the test's SCRATCH_DEV suffers from CPU soft lock-ups during the test. Analysis shows that: fs/nfsd/filecache.c 482 ret = list_lru_walk(&nfsd_file_lru, 483 nfsd_file_lru_cb, 484 &head, LONG_MAX); causes nfsd_file_gc() to walk the entire length of the filecache LRU list every time it is called (which is quite frequently). The walk holds a spinlock the entire time that prevents other nfsd threads from accessing the filecache. What's more, for NFSv4 workloads, none of the items that are visited during this walk may be evicted, since they are all files that are held OPEN by NFS clients. Address this by ensuring that open files are not kept on the LRU list. Reported-by:
Frank van der Linden <fllinden@amazon.com> Reported-by:
Trond Myklebust <trond.myklebust@hammerspace.com> Reviewed-by:
-
Chuck Lever authored
Observe the operation of garbage collection and the lifetime of filecache items. Reviewed-by:
-
Chuck Lever authored
Add a guardrail to prevent freeing memory that is still on a list. This includes either a dispose list or the LRU list. This is the sign of a bug, but this class of bugs can be detected so that they don't endanger system stability, especially while debugging. Reviewed-by:
-
Chuck Lever authored
There has always been the capability of exporting filecache metrics via /proc, but it was never hooked up. Let's surface these metrics to enable better observability of the filecache. Reviewed-by:
-
Chuck Lever authored
If nfsd_file_cache_init() is called after a shutdown, be sure the stat counters are reset. Reviewed-by:
-
Chuck Lever authored
Reviewed-by:
-
Chuck Lever authored
Reviewed-by:
-
Chuck Lever authored
Reviewed-by:
-
Chuck Lever authored
Refactor nfsd_file_gc() to use the new list_lru helper. Reviewed-by:
-
Chuck Lever authored
Refactor the invariant part of nfsd_file_lru_walk_list() into a separate helper function. Reviewed-by:
-
Chuck Lever authored
This is a measure of how long items stay in the filecache, to help assess how efficient the cache is. Reviewed-by:
-
Chuck Lever authored
Surface the count of freed nfsd_file items. Reviewed-by:
-
Chuck Lever authored
Count the number of successful acquisitions that did not create a file (ie, acquisitions that do not result in a compulsory cache miss). This count can be compared directly with the reported hit count to compute a hit ratio. Reviewed-by:
-
Chuck Lever authored
Surface the NFSD filecache's LRU list length to help field troubleshooters monitor filecache issues. Reviewed-by:
-
Chuck Lever authored
The call trace doesn't add much value, but it sure is noisy. Reviewed-by:
-
Chuck Lever authored
Fixes: 37324e6b ("SUNRPC: Cache deferral injection") Signed-off-by:
-
Colin Ian King authored
Variable len is being assigned a value zero and this is never read, it is being re-assigned later. The assignment is redundant and can be removed. Cleans up clang scan-build warning: fs/nfsd/nfsctl.c:636:2: warning: Value stored to 'len' is never read Signed-off-by:
Colin Ian King <colin.i.king@gmail.com> Signed-off-by:
-
Zhang Jiaming authored
Add a blank space after ','. Change 'succesful' to 'successful'. Signed-off-by:
Zhang Jiaming <jiaming@nfschina.com> Signed-off-by:
-
Chuck Lever authored
Capture file handles and how they map to local inodes. In particular, NFSv4 PUTFH uses fh_verify() so we can now observe which file handles are the target of OPEN, LOOKUP, RENAME, and so on. Signed-off-by: -
Chuck Lever authored
Record not only the number of pages requested, but the number of pages that were actually allocated, to get a measure of progress (or lack thereof). Signed-off-by: -
Benjamin Coddington authored
Instead of trusting that struct file_lock returns completely unchanged after vfs_test_lock() when there's no conflicting lock, stash away our nlm_lockowner reference so we can properly release it for all cases. This defends against another file_lock implementation overwriting fl_owner when the return type is F_UNLCK. Reported-by:
Roberto Bergantinos Corpas <rbergant@redhat.com> Tested-by:
Benjamin Coddington <bcodding@redhat.com> Signed-off-by:
-
Chuck Lever authored
I discovered that xdr_encode_bool() was returning the same address that was passed in the @p parameter. The documenting comment states that the intent is to return the address of the next buffer location, just like the other "xdr_encode_*" helpers. The result was the encoded results of NFSv3 PATHCONF operations were not formed correctly. Fixes: ded04a58 ("NFSD: Update the NFSv3 PATHCONF3res encoder to use struct xdr_stream") Signed-off-by:
-
Jeff Layton authored
We had a report from the spring Bake-a-thon of data corruption in some nfstest_interop tests. Looking at the traces showed the NFS server allowing a v3 WRITE to proceed while a read delegation was still outstanding. Currently, we only set NFSD_FILE_BREAK_* flags if NFSD_MAY_NOT_BREAK_LEASE was set when we call nfsd_file_alloc. NFSD_MAY_NOT_BREAK_LEASE was intended to be set when finding files for COMMIT ops, where we need a writeable filehandle but don't need to break read leases. It doesn't make any sense to consult that flag when allocating a file since the file may be used on subsequent calls where we do want to break the lease (and the usage of it here seems to be reverse from what it should be anyway). Also, after calling nfsd_open_break_lease, we don't want to clear the BREAK_* bits. A lease could end up being set on it later (more than once) and we need to be able to break those leases as well. This means that the NFSD_FILE_BREAK_* flags now just mirror NFSD_MAY_{READ,WRITE} flags, so there's no need for them at all. Just drop those flags and unconditionally call nfsd_open_break_lease every time. Reported-by:Olga Kornieskaia <kolga@netapp.com> Link: https://bugzilla.redhat.com/show_bug.cgi?id=2107360 Fixes: 65294c1f (nfsd: add a new struct file caching facility to nfsd) Cc: <stable@vger.kernel.org> # 5.4.x : bb283ca1 NFSD: Clean up the show_nf_flags() macro Cc: <stable@vger.kernel.org> # 5.4.x Signed-off-by:
-
- 17 Jul, 2022 4 commits
-
-
Linus Torvalds authored
-
git://anongit.freedesktop.org/drm/drm-intelLinus Torvalds authored
Pull intel drm build fix from Rodrigo Vivi: "Our 'dim' flow has a problem with fixes of fixes getting missed. We need to take a look on that later. Meanwhile, please allow me to quickly propagate this fix for the 32-bit build issue here upstream" * tag 'drm-intel-fixes-2022-07-17' of git://anongit.freedesktop.org/drm/drm-intel: drm/i915/ttm: fix 32b build
-
Linus Torvalds authored
Merge tag 'perf-tools-fixes-for-v5.19-2022-07-17' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux Pull perf tools fixes from Arnaldo Carvalho de Melo: - Fix SIGSEGV when processing syscall args in perf.data files in 'perf trace' - Sync kvm, msr-index and cpufeatures headers with the kernel sources - Fix 'convert perf time to TSC' 'perf test': - No need to open events twice - Fix finding correct event on hybrid systems * tag 'perf-tools-fixes-for-v5.19-2022-07-17' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux: perf trace: Fix SIGSEGV when processing syscall args perf tests: Fix Convert perf time to TSC test for hybrid perf tests: Stop Convert perf time to TSC test opening events twice tools arch x86: Sync the msr-index.h copy with the kernel sources tools headers cpufeatures: Sync with the kernel sources tools headers UAPI: Sync linux/kvm.h with the kernel sources
-
Matthew Auld authored
Since segment_pages is no longer a compile time constant, it looks the DIV_ROUND_UP(node->size, segment_pages) breaks the 32b build. Simplest is just to use the ULL variant, but really we should need not need more than u32 for the page alignment (also we are limited by that due to the sg->length type), so also make it all u32. Reported-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: aff1e0b0 ("drm/i915/ttm: fix sg_table construction") Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Cc: Nirmoy Das <nirmoy.das@linux.intel.com> Reviewed-by:
Nirmoy Das <nirmoy.das@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220712174050.592550-1-matthew.auld@intel.com (cherry picked from commit 9306b2b2) Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
