search for: i_lock

...running a variant of 2.4.9-34. A certain process is locking access to a filesystem, so that any subsequent access to it hangs the shell. I'm seeing: #ps xwo pid,command,wchan |grep inode 21062 <program name> wait_on_inode Looking at the source code, I can see that the inode attribute I_LOCK is getting set, but for some reason is not being cleared. At the very least, I'd like to know *which* inode is being locked so I can narrow the problem down to an application developed internally and a third-party database. I've tried debugfs and lde, but I can't get either to indicate...

...de(struct btrfs_trans_handle *trans, + struct btrfs_root *root, + struct inode *inode, + struct btrfs_key *key, struct btrfs_path *p, + int ins_len, int cow) +{ + struct extent_buffer *eb; + int cache_level = 0; + int ret; + + if (!p->search_commit_root) { + spin_lock(&inode->i_lock); + if (unlikely(root->objectid == BTRFS_TREE_LOG_OBJECTID)) + eb = BTRFS_I(inode)->log_eb; + else + eb = BTRFS_I(inode)->fs_eb; + + if (eb) + extent_buffer_get(eb); + spin_unlock(&inode->i_lock); + } else { + eb = NULL; + } + + ret = btrfs_search_slot_cache(trans, root,...

Hello, the following series of patches fixes some issues with OCFS2 quotas. The first patch modifies VFS quota locking, the next patch uses the fact to simplify OCFS2 quota locking and solves a few deadlock issues. The third and the fourth patches fix another possible deadlocks in OCFS2 quota code and the last patch is a minor cleanup. Honza

I've been working on a patchset to change how the inode->i_ctime is accessed in order to give us conditional, high-res timestamps for the ctime and mtime. struct timespec64 has unused bits in it that we can use to implement this. In order to do that however, we need to wrap all accesses of inode->i_ctime to ensure that bits used as flags are appropriately handled. This patchset first

...el.kallsyms] [k] update_cfs_rq_blocked_load 2.04% reaim [kernel.kallsyms] [k] mspin_lock 1.30% reaim [kernel.kallsyms] [k] memcpy 1.08% reaim [unknown] [.] 0x0000003c52009447 There was pretty high spinlock contention on the inode_sb_list_lock and maybe the inode's i_lock. With the patch, the perf profile at 1500 users became: 26.82% swapper [kernel.kallsyms] [k] cpu_idle_loop 4.66% reaim [kernel.kallsyms] [k] mutex_spin_on_owner 3.97% reaim [kernel.kallsyms] [k] update_cfs_rq_blocked_load 2.40% reaim [kernel.kallsyms] [k] queue_spin_lock_...

...el.kallsyms] [k] update_cfs_rq_blocked_load 2.04% reaim [kernel.kallsyms] [k] mspin_lock 1.30% reaim [kernel.kallsyms] [k] memcpy 1.08% reaim [unknown] [.] 0x0000003c52009447 There was pretty high spinlock contention on the inode_sb_list_lock and maybe the inode's i_lock. With the patch, the perf profile at 1500 users became: 26.82% swapper [kernel.kallsyms] [k] cpu_idle_loop 4.66% reaim [kernel.kallsyms] [k] mutex_spin_on_owner 3.97% reaim [kernel.kallsyms] [k] update_cfs_rq_blocked_load 2.40% reaim [kernel.kallsyms] [k] queue_spin_lock_...

...el.kallsyms] [k] update_cfs_rq_blocked_load 2.04% reaim [kernel.kallsyms] [k] mspin_lock 1.30% reaim [kernel.kallsyms] [k] memcpy 1.08% reaim [unknown] [.] 0x0000003c52009447 There was pretty high spinlock contention on the inode_sb_list_lock and maybe the inode's i_lock. With the patch, the perf profile at 1500 users became: 26.82% swapper [kernel.kallsyms] [k] cpu_idle_loop 4.66% reaim [kernel.kallsyms] [k] mutex_spin_on_owner 3.97% reaim [kernel.kallsyms] [k] update_cfs_rq_blocked_load 2.40% reaim [kernel.kallsyms] [k] queue_spin_lock_...

v4->v5: - Move the optimized 2-task contending code to the generic file to enable more architectures to use it without code duplication. - Address some of the style-related comments by PeterZ. - Allow the use of unfair queue spinlock in a real para-virtualized execution environment. - Add para-virtualization support to the qspinlock code by ensuring that the lock holder and queue

v4->v5: - Move the optimized 2-task contending code to the generic file to enable more architectures to use it without code duplication. - Address some of the style-related comments by PeterZ. - Allow the use of unfair queue spinlock in a real para-virtualized execution environment. - Add para-virtualization support to the qspinlock code by ensuring that the lock holder and queue

v5->v6: - Change the optimized 2-task contending code to make it fairer at the expense of a bit of performance. - Add a patch to support unfair queue spinlock for Xen. - Modify the PV qspinlock code to follow what was done in the PV ticketlock. - Add performance data for the unfair lock as well as the PV support code. v4->v5: - Move the optimized 2-task contending code to the

v5->v6: - Change the optimized 2-task contending code to make it fairer at the expense of a bit of performance. - Add a patch to support unfair queue spinlock for Xen. - Modify the PV qspinlock code to follow what was done in the PV ticketlock. - Add performance data for the unfair lock as well as the PV support code. v4->v5: - Move the optimized 2-task contending code to the

v6->v7: - Remove an atomic operation from the 2-task contending code - Shorten the names of some macros - Make the queue waiter to attempt to steal lock when unfair lock is enabled. - Remove lock holder kick from the PV code and fix a race condition - Run the unfair lock & PV code on overcommitted KVM guests to collect performance data. v5->v6: - Change the optimized

v6->v7: - Remove an atomic operation from the 2-task contending code - Shorten the names of some macros - Make the queue waiter to attempt to steal lock when unfair lock is enabled. - Remove lock holder kick from the PV code and fix a race condition - Run the unfair lock & PV code on overcommitted KVM guests to collect performance data. v5->v6: - Change the optimized

v7->v8: - Remove one unneeded atomic operation from the slowpath, thus improving performance. - Simplify some of the codes and add more comments. - Test for X86_FEATURE_HYPERVISOR CPU feature bit to enable/disable unfair lock. - Reduce unfair lock slowpath lock stealing frequency depending on its distance from the queue head. - Add performance data for IvyBridge-EX CPU.

v7->v8: - Remove one unneeded atomic operation from the slowpath, thus improving performance. - Simplify some of the codes and add more comments. - Test for X86_FEATURE_HYPERVISOR CPU feature bit to enable/disable unfair lock. - Reduce unfair lock slowpath lock stealing frequency depending on its distance from the queue head. - Add performance data for IvyBridge-EX CPU.

v4->v5: - Move the optimized 2-task contending code to the generic file to enable more architectures to use it without code duplication. - Address some of the style-related comments by PeterZ. - Allow the use of unfair queue spinlock in a real para-virtualized execution environment. - Add para-virtualization support to the qspinlock code by ensuring that the lock holder and queue

v4->v5: - Move the optimized 2-task contending code to the generic file to enable more architectures to use it without code duplication. - Address some of the style-related comments by PeterZ. - Allow the use of unfair queue spinlock in a real para-virtualized execution environment. - Add para-virtualization support to the qspinlock code by ensuring that the lock holder and queue

N.B. Sorry for the duplicate. This patch series were resent as the original one was rejected by the vger.kernel.org list server due to long header. There is no change in content. v7->v8: - Remove one unneeded atomic operation from the slowpath, thus improving performance. - Simplify some of the codes and add more comments. - Test for X86_FEATURE_HYPERVISOR CPU feature bit

N.B. Sorry for the duplicate. This patch series were resent as the original one was rejected by the vger.kernel.org list server due to long header. There is no change in content. v7->v8: - Remove one unneeded atomic operation from the slowpath, thus improving performance. - Simplify some of the codes and add more comments. - Test for X86_FEATURE_HYPERVISOR CPU feature bit