* VFS scalability git tree @ 2010-07-22 19:01 ` Nick Piggin 0 siblings, 0 replies; 76+ messages in thread From: Nick Piggin @ 2010-07-22 19:01 UTC (permalink / raw) To: linux-fsdevel, linux-kernel, linux-mm; +Cc: Frank Mayhar, John Stultz I'm pleased to announce I have a git tree up of my vfs scalability work. git://git.kernel.org/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git http://git.kernel.org/?p=linux/kernel/git/npiggin/linux-npiggin.git Branch vfs-scale-working The really interesting new item is the store-free path walk, (43fe2b) which I've re-introduced. It has had a complete redesign, it has much better performance and scalability in more cases, and is actually sane code now. What this does is to allow parallel name lookups to walk down common elements without any cacheline bouncing between them. It can walk across many interesting cases such as mount points, back up '..', and negative dentries of most filesystems. It does so without requiring any atomic operations or any stores at all to hared data. This also makes it very fast in serial performance (path walking is nearly twice as fast on my Opteron). In cases where it cannot continue the RCU walk (eg. dentry does not exist), then it can in most cases take a reference on the farthest element it has reached so far, and then continue on with a regular refcount-based path walk. My first attempt at this simply dropped everything and re-did the full refcount based walk. I've also been working on stress testing, bug fixing, cutting down 'XXX'es, and improving changelogs and comments. Most filesystems are untested (it's too large a job to do comprehensive stress tests on everything), but none have known issues (except nilfs2). Ext2/3, nfs, nfsd, and ram based filesystems seem to work well, ext4/btrfs/xfs/autofs4 have had light testing. I've never had filesystem corruption when testing these patches (only lockups or other bugs). But standard disclaimer: they may eat your data. Summary of a few numbers I've run. google's socket teardown workload runs 3-4x faster on my 2 socket Opteron. Single thread git diff runs 20% on same machine. 32 node Altix runs dbench on ramfs 150x faster (100MB/s up to 15GB/s). At this point, I would be very interested in reviewing, correctness testing on different configurations, and of course benchmarking. Thanks, Nick ^ permalink raw reply [flat|nested] 76+ messages in thread
* VFS scalability git tree @ 2010-07-22 19:01 ` Nick Piggin 0 siblings, 0 replies; 76+ messages in thread From: Nick Piggin @ 2010-07-22 19:01 UTC (permalink / raw) To: linux-fsdevel, linux-kernel, linux-mm; +Cc: Frank Mayhar, John Stultz I'm pleased to announce I have a git tree up of my vfs scalability work. git://git.kernel.org/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git http://git.kernel.org/?p=linux/kernel/git/npiggin/linux-npiggin.git Branch vfs-scale-working The really interesting new item is the store-free path walk, (43fe2b) which I've re-introduced. It has had a complete redesign, it has much better performance and scalability in more cases, and is actually sane code now. What this does is to allow parallel name lookups to walk down common elements without any cacheline bouncing between them. It can walk across many interesting cases such as mount points, back up '..', and negative dentries of most filesystems. It does so without requiring any atomic operations or any stores at all to hared data. This also makes it very fast in serial performance (path walking is nearly twice as fast on my Opteron). In cases where it cannot continue the RCU walk (eg. dentry does not exist), then it can in most cases take a reference on the farthest element it has reached so far, and then continue on with a regular refcount-based path walk. My first attempt at this simply dropped everything and re-did the full refcount based walk. I've also been working on stress testing, bug fixing, cutting down 'XXX'es, and improving changelogs and comments. Most filesystems are untested (it's too large a job to do comprehensive stress tests on everything), but none have known issues (except nilfs2). Ext2/3, nfs, nfsd, and ram based filesystems seem to work well, ext4/btrfs/xfs/autofs4 have had light testing. I've never had filesystem corruption when testing these patches (only lockups or other bugs). But standard disclaimer: they may eat your data. Summary of a few numbers I've run. google's socket teardown workload runs 3-4x faster on my 2 socket Opteron. Single thread git diff runs 20% on same machine. 32 node Altix runs dbench on ramfs 150x faster (100MB/s up to 15GB/s). At this point, I would be very interested in reviewing, correctness testing on different configurations, and of course benchmarking. Thanks, Nick -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: VFS scalability git tree 2010-07-22 19:01 ` Nick Piggin @ 2010-07-23 11:13 ` Dave Chinner -1 siblings, 0 replies; 76+ messages in thread From: Dave Chinner @ 2010-07-23 11:13 UTC (permalink / raw) To: Nick Piggin Cc: linux-fsdevel, linux-kernel, linux-mm, Frank Mayhar, John Stultz On Fri, Jul 23, 2010 at 05:01:00AM +1000, Nick Piggin wrote: > I'm pleased to announce I have a git tree up of my vfs scalability work. > > git://git.kernel.org/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git > http://git.kernel.org/?p=linux/kernel/git/npiggin/linux-npiggin.git > > Branch vfs-scale-working I've got a couple of patches needed to build XFS - they shrinker merge left some bad fragments - I'll post them in a minute. This email is for the longest ever lockdep warning I've seen that occurred on boot. Cheers, Dave. [ 6.368707] ====================================================== [ 6.369773] [ INFO: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected ] [ 6.370379] 2.6.35-rc5-dgc+ #58 [ 6.370882] ------------------------------------------------------ [ 6.371475] pmcd/2124 [HC0[0]:SC0[1]:HE1:SE0] is trying to acquire: [ 6.372062] (&sb->s_type->i_lock_key#6){+.+...}, at: [<ffffffff81736f8c>] socket_get_id+0x3c/0x60 [ 6.372268] [ 6.372268] and this task is already holding: [ 6.372268] (&(&hashinfo->ehash_locks[i])->rlock){+.-...}, at: [<ffffffff81791750>] established_get_first+0x60/0x120 [ 6.372268] which would create a new lock dependency: [ 6.372268] (&(&hashinfo->ehash_locks[i])->rlock){+.-...} -> (&sb->s_type->i_lock_key#6){+.+...} [ 6.372268] [ 6.372268] but this new dependency connects a SOFTIRQ-irq-safe lock: [ 6.372268] (&(&hashinfo->ehash_locks[i])->rlock){+.-...} [ 6.372268] ... which became SOFTIRQ-irq-safe at: [ 6.372268] [<ffffffff810b3b26>] __lock_acquire+0x576/0x1450 [ 6.372268] [<ffffffff810b4aa6>] lock_acquire+0xa6/0x160 [ 6.372268] [<ffffffff8182bb26>] _raw_spin_lock+0x36/0x70 [ 6.372268] [<ffffffff8177a1ba>] __inet_hash_nolisten+0xfa/0x180 [ 6.372268] [<ffffffff8179392a>] tcp_v4_syn_recv_sock+0x1aa/0x2d0 [ 6.372268] [<ffffffff81795502>] tcp_check_req+0x202/0x440 [ 6.372268] [<ffffffff817948c4>] tcp_v4_do_rcv+0x304/0x4f0 [ 6.372268] [<ffffffff81795134>] tcp_v4_rcv+0x684/0x7e0 [ 6.372268] [<ffffffff81771512>] ip_local_deliver+0xe2/0x1c0 [ 6.372268] [<ffffffff81771af7>] ip_rcv+0x397/0x760 [ 6.372268] [<ffffffff8174d067>] __netif_receive_skb+0x277/0x330 [ 6.372268] [<ffffffff8174d1f4>] process_backlog+0xd4/0x1e0 [ 6.372268] [<ffffffff8174dc38>] net_rx_action+0x188/0x2b0 [ 6.372268] [<ffffffff81084cc2>] __do_softirq+0xd2/0x260 [ 6.372268] [<ffffffff81035edc>] call_softirq+0x1c/0x50 [ 6.372268] [<ffffffff8108551b>] local_bh_enable_ip+0xeb/0xf0 [ 6.372268] [<ffffffff8182c544>] _raw_spin_unlock_bh+0x34/0x40 [ 6.372268] [<ffffffff8173c59e>] release_sock+0x14e/0x1a0 [ 6.372268] [<ffffffff817a3975>] inet_stream_connect+0x75/0x320 [ 6.372268] [<ffffffff81737917>] sys_connect+0xa7/0xc0 [ 6.372268] [<ffffffff81034ff2>] system_call_fastpath+0x16/0x1b [ 6.372268] [ 6.372268] to a SOFTIRQ-irq-unsafe lock: [ 6.372268] (&sb->s_type->i_lock_key#6){+.+...} [ 6.372268] ... which became SOFTIRQ-irq-unsafe at: [ 6.372268] ... [<ffffffff810b3b73>] __lock_acquire+0x5c3/0x1450 [ 6.372268] [<ffffffff810b4aa6>] lock_acquire+0xa6/0x160 [ 6.372268] [<ffffffff8182bb26>] _raw_spin_lock+0x36/0x70 [ 6.372268] [<ffffffff8116af72>] new_inode+0x52/0xd0 [ 6.372268] [<ffffffff81174a40>] get_sb_pseudo+0xb0/0x180 [ 6.372268] [<ffffffff81735a41>] sockfs_get_sb+0x21/0x30 [ 6.372268] [<ffffffff81152dba>] vfs_kern_mount+0x8a/0x1e0 [ 6.372268] [<ffffffff81152f29>] kern_mount_data+0x19/0x20 [ 6.372268] [<ffffffff81e1c075>] sock_init+0x4e/0x59 [ 6.372268] [<ffffffff810001dc>] do_one_initcall+0x3c/0x1a0 [ 6.372268] [<ffffffff81de5767>] kernel_init+0x17a/0x204 [ 6.372268] [<ffffffff81035de4>] kernel_thread_helper+0x4/0x10 [ 6.372268] [ 6.372268] other info that might help us debug this: [ 6.372268] [ 6.372268] 3 locks held by pmcd/2124: [ 6.372268] #0: (&p->lock){+.+.+.}, at: [<ffffffff81171dae>] seq_read+0x3e/0x430 [ 6.372268] #1: (&(&hashinfo->ehash_locks[i])->rlock){+.-...}, at: [<ffffffff81791750>] established_get_first+0x60/0x120 [ 6.372268] #2: (clock-AF_INET){++....}, at: [<ffffffff8173b6ae>] sock_i_ino+0x2e/0x70 [ 6.372268] [ 6.372268] the dependencies between SOFTIRQ-irq-safe lock and the holding lock: [ 6.372268] -> (&(&hashinfo->ehash_locks[i])->rlock){+.-...} ops: 3 { [ 6.372268] HARDIRQ-ON-W at: [ 6.372268] [<ffffffff810b3b47>] __lock_acquire+0x597/0x1450 [ 6.372268] [<ffffffff810b4aa6>] lock_acquire+0xa6/0x160 [ 6.372268] [<ffffffff8182bb26>] _raw_spin_lock+0x36/0x70 [ 6.372268] [<ffffffff8177a1ba>] __inet_hash_nolisten+0xfa/0x180 [ 6.372268] [<ffffffff8177ab6a>] __inet_hash_connect+0x33a/0x3d0 [ 6.372268] [<ffffffff8177ac4f>] inet_hash_connect+0x4f/0x60 [ 6.372268] [<ffffffff81792522>] tcp_v4_connect+0x272/0x4f0 [ 6.372268] [<ffffffff817a3b8e>] inet_stream_connect+0x28e/0x320 [ 6.372268] [<ffffffff81737917>] sys_connect+0xa7/0xc0 [ 6.372268] [<ffffffff81034ff2>] system_call_fastpath+0x16/0x1b [ 6.372268] IN-SOFTIRQ-W at: [ 6.372268] [<ffffffff810b3b26>] __lock_acquire+0x576/0x1450 [ 6.372268] [<ffffffff810b4aa6>] lock_acquire+0xa6/0x160 [ 6.372268] [<ffffffff8182bb26>] _raw_spin_lock+0x36/0x70 [ 6.372268] [<ffffffff8177a1ba>] __inet_hash_nolisten+0xfa/0x180 [ 6.372268] [<ffffffff8179392a>] tcp_v4_syn_recv_sock+0x1aa/0x2d0 [ 6.372268] [<ffffffff81795502>] tcp_check_req+0x202/0x440 [ 6.372268] [<ffffffff817948c4>] tcp_v4_do_rcv+0x304/0x4f0 [ 6.372268] [<ffffffff81795134>] tcp_v4_rcv+0x684/0x7e0 [ 6.372268] [<ffffffff81771512>] ip_local_deliver+0xe2/0x1c0 [ 6.372268] [<ffffffff81771af7>] ip_rcv+0x397/0x760 [ 6.372268] [<ffffffff8174d067>] __netif_receive_skb+0x277/0x330 [ 6.372268] [<ffffffff8174d1f4>] process_backlog+0xd4/0x1e0 [ 6.372268] [<ffffffff8174dc38>] net_rx_action+0x188/0x2b0 [ 6.372268] [<ffffffff81084cc2>] __do_softirq+0xd2/0x260 [ 6.372268] [<ffffffff81035edc>] call_softirq+0x1c/0x50 [ 6.372268] [<ffffffff8108551b>] local_bh_enable_ip+0xeb/0xf0 [ 6.372268] [<ffffffff8182c544>] _raw_spin_unlock_bh+0x34/0x40 [ 6.372268] [<ffffffff8173c59e>] release_sock+0x14e/0x1a0 [ 6.372268] [<ffffffff817a3975>] inet_stream_connect+0x75/0x320 [ 6.372268] [<ffffffff81737917>] sys_connect+0xa7/0xc0 [ 6.372268] [<ffffffff81034ff2>] system_call_fastpath+0x16/0x1b [ 6.372268] INITIAL USE at: [ 6.372268] [<ffffffff810b37e2>] __lock_acquire+0x232/0x1450 [ 6.372268] [<ffffffff810b4aa6>] lock_acquire+0xa6/0x160 [ 6.372268] [<ffffffff8182bb26>] _raw_spin_lock+0x36/0x70 [ 6.372268] [<ffffffff8177a1ba>] __inet_hash_nolisten+0xfa/0x180 [ 6.372268] [<ffffffff8177ab6a>] __inet_hash_connect+0x33a/0x3d0 [ 6.372268] [<ffffffff8177ac4f>] inet_hash_connect+0x4f/0x60 [ 6.372268] [<ffffffff81792522>] tcp_v4_connect+0x272/0x4f0 [ 6.372268] [<ffffffff817a3b8e>] inet_stream_connect+0x28e/0x320 [ 6.372268] [<ffffffff81737917>] sys_connect+0xa7/0xc0 [ 6.372268] [<ffffffff81034ff2>] system_call_fastpath+0x16/0x1b [ 6.372268] } [ 6.372268] ... key at: [<ffffffff8285ddf8>] __key.47027+0x0/0x8 [ 6.372268] ... acquired at: [ 6.372268] [<ffffffff810b2940>] check_irq_usage+0x60/0xf0 [ 6.372268] [<ffffffff810b41ff>] __lock_acquire+0xc4f/0x1450 [ 6.372268] [<ffffffff810b4aa6>] lock_acquire+0xa6/0x160 [ 6.372268] [<ffffffff8182bb26>] _raw_spin_lock+0x36/0x70 [ 6.372268] [<ffffffff81736f8c>] socket_get_id+0x3c/0x60 [ 6.372268] [<ffffffff8173b6c3>] sock_i_ino+0x43/0x70 [ 6.372268] [<ffffffff81790fc9>] tcp4_seq_show+0x1a9/0x520 [ 6.372268] [<ffffffff81172005>] seq_read+0x295/0x430 [ 6.372268] [<ffffffff811ad9f4>] proc_reg_read+0x84/0xc0 [ 6.372268] [<ffffffff81150165>] vfs_read+0xb5/0x170 [ 6.372268] [<ffffffff81150274>] sys_read+0x54/0x90 [ 6.372268] [<ffffffff81034ff2>] system_call_fastpath+0x16/0x1b [ 6.372268] [ 6.372268] [ 6.372268] the dependencies between the lock to be acquired and SOFTIRQ-irq-unsafe lock: [ 6.372268] -> (&sb->s_type->i_lock_key#6){+.+...} ops: 1185 { [ 6.372268] HARDIRQ-ON-W at: [ 6.372268] [<ffffffff810b3b47>] __lock_acquire+0x597/0x1450 [ 6.372268] [<ffffffff810b4aa6>] lock_acquire+0xa6/0x160 [ 6.372268] [<ffffffff8182bb26>] _raw_spin_lock+0x36/0x70 [ 6.372268] [<ffffffff8116af72>] new_inode+0x52/0xd0 [ 6.372268] [<ffffffff81174a40>] get_sb_pseudo+0xb0/0x180 [ 6.372268] [<ffffffff81735a41>] sockfs_get_sb+0x21/0x30 [ 6.372268] [<ffffffff81152dba>] vfs_kern_mount+0x8a/0x1e0 [ 6.372268] [<ffffffff81152f29>] kern_mount_data+0x19/0x20 [ 6.372268] [<ffffffff81e1c075>] sock_init+0x4e/0x59 [ 6.372268] [<ffffffff810001dc>] do_one_initcall+0x3c/0x1a0 [ 6.372268] [<ffffffff81de5767>] kernel_init+0x17a/0x204 [ 6.372268] [<ffffffff81035de4>] kernel_thread_helper+0x4/0x10 [ 6.372268] SOFTIRQ-ON-W at: [ 6.372268] [<ffffffff810b3b73>] __lock_acquire+0x5c3/0x1450 [ 6.372268] [<ffffffff810b4aa6>] lock_acquire+0xa6/0x160 [ 6.372268] [<ffffffff8182bb26>] _raw_spin_lock+0x36/0x70 [ 6.372268] [<ffffffff8116af72>] new_inode+0x52/0xd0 [ 6.372268] [<ffffffff81174a40>] get_sb_pseudo+0xb0/0x180 [ 6.372268] [<ffffffff81735a41>] sockfs_get_sb+0x21/0x30 [ 6.372268] [<ffffffff81152dba>] vfs_kern_mount+0x8a/0x1e0 [ 6.372268] [<ffffffff81152f29>] kern_mount_data+0x19/0x20 [ 6.372268] [<ffffffff81e1c075>] sock_init+0x4e/0x59 [ 6.372268] [<ffffffff810001dc>] do_one_initcall+0x3c/0x1a0 [ 6.372268] [<ffffffff81de5767>] kernel_init+0x17a/0x204 [ 6.372268] [<ffffffff81035de4>] kernel_thread_helper+0x4/0x10 [ 6.372268] INITIAL USE at: [ 6.372268] [<ffffffff810b37e2>] __lock_acquire+0x232/0x1450 [ 6.372268] [<ffffffff810b4aa6>] lock_acquire+0xa6/0x160 [ 6.372268] [<ffffffff8182bb26>] _raw_spin_lock+0x36/0x70 [ 6.372268] [<ffffffff8116af72>] new_inode+0x52/0xd0 [ 6.372268] [<ffffffff81174a40>] get_sb_pseudo+0xb0/0x180 [ 6.372268] [<f [<ffffffff81152dba>] vfs_kern_mount+0x8a/0x1e0 [ 6.372268] [<ffffffff81152f29>] kern_mount_data+0x19/0x20 [ 6.372268] [<ffffffff81e1c075>] sock_init+0x4e/0x59 [ 6.372268] [<ffffffff810001dc>] do_one_initcall+0x3c/0x1a0 [ 6.372268] [<ffffffff81de5767>] kernel_init+0x17a/0x204 [ 6.372268] [<ffffffff81035de4>] kernel_thread_helper+0x4/0x10 [ 6.372268] } [ 6.372268] ... key at: [<ffffffff81bd5bd8>] sock_fs_type+0x58/0x80 [ 6.372268] ... acquired at: [ 6.372268] [<ffffffff810b2940>] check_irq_usage+0x60/0xf0 [ 6.372268] [<ffffffff810b41ff>] __lock_acquire+0xc4f/0x1450 [ 6.372268] [<ffffffff810b4aa6>] lock_acquire+0xa6/0x160 [ 6.372268] [<ffffffff8182bb26>] _raw_spin_lock+0x36/0x70 [ 6.372268] [<ffffffff81736f8c>] socket_get_id+0x3c/0x60 [ 6.372268] [<ffffffff8173b6c3>] sock_i_ino+0x43/0x70 [ 6.372268] [<ffffffff81790fc9>] tcp4_seq_show+0x1a9/0x520 [ 6.372268] [<ffffffff81172005>] seq_read+0x295/0x430 [ 6.372268] [<ffffffff811ad9f4>] proc_reg_read+0x84/0xc0 [ 6.372268] [<ffffffff81150165>] vfs_read+0xb5/0x170 [ 6.372268] [<ffffffff81150274>] sys_read+0x54/0x90 [ 6.372268] [<ffffffff81034ff2>] system_call_fastpath+0x16/0x1b [ 6.372268] [ 6.372268] [ 6.372268] stack backtrace: [ 6.372268] Pid: 2124, comm: pmcd Not tainted 2.6.35-rc5-dgc+ #58 [ 6.372268] Call Trace: [ 6.372268] [<ffffffff810b28d9>] check_usage+0x499/0x4a0 [ 6.372268] [<ffffffff810b24c6>] ? check_usage+0x86/0x4a0 [ 6.372268] [<ffffffff810af729>] ? __bfs+0x129/0x260 [ 6.372268] [<ffffffff810b2940>] check_irq_usage+0x60/0xf0 [ 6.372268] [<ffffffff810b41ff>] __lock_acquire+0xc4f/0x1450 [ 6.372268] [<ffffffff810b4aa6>] lock_acquire+0xa6/0x160 [ 6.372268] [<ffffffff81736f8c>] ? socket_get_id+0x3c/0x60 [ 6.372268] [<ffffffff8182bb26>] _raw_spin_lock+0x36/0x70 [ 6.372268] [<ffffffff81736f8c>] ? socket_get_id+0x3c/0x60 [ 6.372268] [<ffffffff81736f8c>] socket_get_id+0x3c/0x60 [ 6.372268] [<ffffffff8173b6c3>] sock_i_ino+0x43/0x70 [ 6.372268] [<ffffffff81790fc9>] tcp4_seq_show+0x1a9/0x520 [ 6.372268] [<ffffffff81791750>] ? established_get_first+0x60/0x120 [ 6.372268] [<ffffffff8182beb7>] ? _raw_spin_lock_bh+0x67/0x70 [ 6.372268] [<ffffffff81172005>] seq_read+0x295/0x430 [ 6.372268] [<ffffffff81171d70>] ? seq_read+0x0/0x430 [ 6.372268] [<ffffffff811ad9f4>] proc_reg_read+0x84/0xc0 [ 6.372268] [<ffffffff81150165>] vfs_read+0xb5/0x170 [ 6.372268] [<ffffffff81150274>] sys_read+0x54/0x90 [ 6.372268] [<ffffffff81034ff2>] system_call_fastpath+0x16/0x1b -- Dave Chinner david@fromorbit.com ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: VFS scalability git tree @ 2010-07-23 11:13 ` Dave Chinner 0 siblings, 0 replies; 76+ messages in thread From: Dave Chinner @ 2010-07-23 11:13 UTC (permalink / raw) To: Nick Piggin Cc: linux-fsdevel, linux-kernel, linux-mm, Frank Mayhar, John Stultz On Fri, Jul 23, 2010 at 05:01:00AM +1000, Nick Piggin wrote: > I'm pleased to announce I have a git tree up of my vfs scalability work. > > git://git.kernel.org/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git > http://git.kernel.org/?p=linux/kernel/git/npiggin/linux-npiggin.git > > Branch vfs-scale-working I've got a couple of patches needed to build XFS - they shrinker merge left some bad fragments - I'll post them in a minute. This email is for the longest ever lockdep warning I've seen that occurred on boot. Cheers, Dave. [ 6.368707] ====================================================== [ 6.369773] [ INFO: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected ] [ 6.370379] 2.6.35-rc5-dgc+ #58 [ 6.370882] ------------------------------------------------------ [ 6.371475] pmcd/2124 [HC0[0]:SC0[1]:HE1:SE0] is trying to acquire: [ 6.372062] (&sb->s_type->i_lock_key#6){+.+...}, at: [<ffffffff81736f8c>] socket_get_id+0x3c/0x60 [ 6.372268] [ 6.372268] and this task is already holding: [ 6.372268] (&(&hashinfo->ehash_locks[i])->rlock){+.-...}, at: [<ffffffff81791750>] established_get_first+0x60/0x120 [ 6.372268] which would create a new lock dependency: [ 6.372268] (&(&hashinfo->ehash_locks[i])->rlock){+.-...} -> (&sb->s_type->i_lock_key#6){+.+...} [ 6.372268] [ 6.372268] but this new dependency connects a SOFTIRQ-irq-safe lock: [ 6.372268] (&(&hashinfo->ehash_locks[i])->rlock){+.-...} [ 6.372268] ... which became SOFTIRQ-irq-safe at: [ 6.372268] [<ffffffff810b3b26>] __lock_acquire+0x576/0x1450 [ 6.372268] [<ffffffff810b4aa6>] lock_acquire+0xa6/0x160 [ 6.372268] [<ffffffff8182bb26>] _raw_spin_lock+0x36/0x70 [ 6.372268] [<ffffffff8177a1ba>] __inet_hash_nolisten+0xfa/0x180 [ 6.372268] [<ffffffff8179392a>] tcp_v4_syn_recv_sock+0x1aa/0x2d0 [ 6.372268] [<ffffffff81795502>] tcp_check_req+0x202/0x440 [ 6.372268] [<ffffffff817948c4>] tcp_v4_do_rcv+0x304/0x4f0 [ 6.372268] [<ffffffff81795134>] tcp_v4_rcv+0x684/0x7e0 [ 6.372268] [<ffffffff81771512>] ip_local_deliver+0xe2/0x1c0 [ 6.372268] [<ffffffff81771af7>] ip_rcv+0x397/0x760 [ 6.372268] [<ffffffff8174d067>] __netif_receive_skb+0x277/0x330 [ 6.372268] [<ffffffff8174d1f4>] process_backlog+0xd4/0x1e0 [ 6.372268] [<ffffffff8174dc38>] net_rx_action+0x188/0x2b0 [ 6.372268] [<ffffffff81084cc2>] __do_softirq+0xd2/0x260 [ 6.372268] [<ffffffff81035edc>] call_softirq+0x1c/0x50 [ 6.372268] [<ffffffff8108551b>] local_bh_enable_ip+0xeb/0xf0 [ 6.372268] [<ffffffff8182c544>] _raw_spin_unlock_bh+0x34/0x40 [ 6.372268] [<ffffffff8173c59e>] release_sock+0x14e/0x1a0 [ 6.372268] [<ffffffff817a3975>] inet_stream_connect+0x75/0x320 [ 6.372268] [<ffffffff81737917>] sys_connect+0xa7/0xc0 [ 6.372268] [<ffffffff81034ff2>] system_call_fastpath+0x16/0x1b [ 6.372268] [ 6.372268] to a SOFTIRQ-irq-unsafe lock: [ 6.372268] (&sb->s_type->i_lock_key#6){+.+...} [ 6.372268] ... which became SOFTIRQ-irq-unsafe at: [ 6.372268] ... [<ffffffff810b3b73>] __lock_acquire+0x5c3/0x1450 [ 6.372268] [<ffffffff810b4aa6>] lock_acquire+0xa6/0x160 [ 6.372268] [<ffffffff8182bb26>] _raw_spin_lock+0x36/0x70 [ 6.372268] [<ffffffff8116af72>] new_inode+0x52/0xd0 [ 6.372268] [<ffffffff81174a40>] get_sb_pseudo+0xb0/0x180 [ 6.372268] [<ffffffff81735a41>] sockfs_get_sb+0x21/0x30 [ 6.372268] [<ffffffff81152dba>] vfs_kern_mount+0x8a/0x1e0 [ 6.372268] [<ffffffff81152f29>] kern_mount_data+0x19/0x20 [ 6.372268] [<ffffffff81e1c075>] sock_init+0x4e/0x59 [ 6.372268] [<ffffffff810001dc>] do_one_initcall+0x3c/0x1a0 [ 6.372268] [<ffffffff81de5767>] kernel_init+0x17a/0x204 [ 6.372268] [<ffffffff81035de4>] kernel_thread_helper+0x4/0x10 [ 6.372268] [ 6.372268] other info that might help us debug this: [ 6.372268] [ 6.372268] 3 locks held by pmcd/2124: [ 6.372268] #0: (&p->lock){+.+.+.}, at: [<ffffffff81171dae>] seq_read+0x3e/0x430 [ 6.372268] #1: (&(&hashinfo->ehash_locks[i])->rlock){+.-...}, at: [<ffffffff81791750>] established_get_first+0x60/0x120 [ 6.372268] #2: (clock-AF_INET){++....}, at: [<ffffffff8173b6ae>] sock_i_ino+0x2e/0x70 [ 6.372268] [ 6.372268] the dependencies between SOFTIRQ-irq-safe lock and the holding lock: [ 6.372268] -> (&(&hashinfo->ehash_locks[i])->rlock){+.-...} ops: 3 { [ 6.372268] HARDIRQ-ON-W at: [ 6.372268] [<ffffffff810b3b47>] __lock_acquire+0x597/0x1450 [ 6.372268] [<ffffffff810b4aa6>] lock_acquire+0xa6/0x160 [ 6.372268] [<ffffffff8182bb26>] _raw_spin_lock+0x36/0x70 [ 6.372268] [<ffffffff8177a1ba>] __inet_hash_nolisten+0xfa/0x180 [ 6.372268] [<ffffffff8177ab6a>] __inet_hash_connect+0x33a/0x3d0 [ 6.372268] [<ffffffff8177ac4f>] inet_hash_connect+0x4f/0x60 [ 6.372268] [<ffffffff81792522>] tcp_v4_connect+0x272/0x4f0 [ 6.372268] [<ffffffff817a3b8e>] inet_stream_connect+0x28e/0x320 [ 6.372268] [<ffffffff81737917>] sys_connect+0xa7/0xc0 [ 6.372268] [<ffffffff81034ff2>] system_call_fastpath+0x16/0x1b [ 6.372268] IN-SOFTIRQ-W at: [ 6.372268] [<ffffffff810b3b26>] __lock_acquire+0x576/0x1450 [ 6.372268] [<ffffffff810b4aa6>] lock_acquire+0xa6/0x160 [ 6.372268] [<ffffffff8182bb26>] _raw_spin_lock+0x36/0x70 [ 6.372268] [<ffffffff8177a1ba>] __inet_hash_nolisten+0xfa/0x180 [ 6.372268] [<ffffffff8179392a>] tcp_v4_syn_recv_sock+0x1aa/0x2d0 [ 6.372268] [<ffffffff81795502>] tcp_check_req+0x202/0x440 [ 6.372268] [<ffffffff817948c4>] tcp_v4_do_rcv+0x304/0x4f0 [ 6.372268] [<ffffffff81795134>] tcp_v4_rcv+0x684/0x7e0 [ 6.372268] [<ffffffff81771512>] ip_local_deliver+0xe2/0x1c0 [ 6.372268] [<ffffffff81771af7>] ip_rcv+0x397/0x760 [ 6.372268] [<ffffffff8174d067>] __netif_receive_skb+0x277/0x330 [ 6.372268] [<ffffffff8174d1f4>] process_backlog+0xd4/0x1e0 [ 6.372268] [<ffffffff8174dc38>] net_rx_action+0x188/0x2b0 [ 6.372268] [<ffffffff81084cc2>] __do_softirq+0xd2/0x260 [ 6.372268] [<ffffffff81035edc>] call_softirq+0x1c/0x50 [ 6.372268] [<ffffffff8108551b>] local_bh_enable_ip+0xeb/0xf0 [ 6.372268] [<ffffffff8182c544>] _raw_spin_unlock_bh+0x34/0x40 [ 6.372268] [<ffffffff8173c59e>] release_sock+0x14e/0x1a0 [ 6.372268] [<ffffffff817a3975>] inet_stream_connect+0x75/0x320 [ 6.372268] [<ffffffff81737917>] sys_connect+0xa7/0xc0 [ 6.372268] [<ffffffff81034ff2>] system_call_fastpath+0x16/0x1b [ 6.372268] INITIAL USE at: [ 6.372268] [<ffffffff810b37e2>] __lock_acquire+0x232/0x1450 [ 6.372268] [<ffffffff810b4aa6>] lock_acquire+0xa6/0x160 [ 6.372268] [<ffffffff8182bb26>] _raw_spin_lock+0x36/0x70 [ 6.372268] [<ffffffff8177a1ba>] __inet_hash_nolisten+0xfa/0x180 [ 6.372268] [<ffffffff8177ab6a>] __inet_hash_connect+0x33a/0x3d0 [ 6.372268] [<ffffffff8177ac4f>] inet_hash_connect+0x4f/0x60 [ 6.372268] [<ffffffff81792522>] tcp_v4_connect+0x272/0x4f0 [ 6.372268] [<ffffffff817a3b8e>] inet_stream_connect+0x28e/0x320 [ 6.372268] [<ffffffff81737917>] sys_connect+0xa7/0xc0 [ 6.372268] [<ffffffff81034ff2>] system_call_fastpath+0x16/0x1b [ 6.372268] } [ 6.372268] ... key at: [<ffffffff8285ddf8>] __key.47027+0x0/0x8 [ 6.372268] ... acquired at: [ 6.372268] [<ffffffff810b2940>] check_irq_usage+0x60/0xf0 [ 6.372268] [<ffffffff810b41ff>] __lock_acquire+0xc4f/0x1450 [ 6.372268] [<ffffffff810b4aa6>] lock_acquire+0xa6/0x160 [ 6.372268] [<ffffffff8182bb26>] _raw_spin_lock+0x36/0x70 [ 6.372268] [<ffffffff81736f8c>] socket_get_id+0x3c/0x60 [ 6.372268] [<ffffffff8173b6c3>] sock_i_ino+0x43/0x70 [ 6.372268] [<ffffffff81790fc9>] tcp4_seq_show+0x1a9/0x520 [ 6.372268] [<ffffffff81172005>] seq_read+0x295/0x430 [ 6.372268] [<ffffffff811ad9f4>] proc_reg_read+0x84/0xc0 [ 6.372268] [<ffffffff81150165>] vfs_read+0xb5/0x170 [ 6.372268] [<ffffffff81150274>] sys_read+0x54/0x90 [ 6.372268] [<ffffffff81034ff2>] system_call_fastpath+0x16/0x1b [ 6.372268] [ 6.372268] [ 6.372268] the dependencies between the lock to be acquired and SOFTIRQ-irq-unsafe lock: [ 6.372268] -> (&sb->s_type->i_lock_key#6){+.+...} ops: 1185 { [ 6.372268] HARDIRQ-ON-W at: [ 6.372268] [<ffffffff810b3b47>] __lock_acquire+0x597/0x1450 [ 6.372268] [<ffffffff810b4aa6>] lock_acquire+0xa6/0x160 [ 6.372268] [<ffffffff8182bb26>] _raw_spin_lock+0x36/0x70 [ 6.372268] [<ffffffff8116af72>] new_inode+0x52/0xd0 [ 6.372268] [<ffffffff81174a40>] get_sb_pseudo+0xb0/0x180 [ 6.372268] [<ffffffff81735a41>] sockfs_get_sb+0x21/0x30 [ 6.372268] [<ffffffff81152dba>] vfs_kern_mount+0x8a/0x1e0 [ 6.372268] [<ffffffff81152f29>] kern_mount_data+0x19/0x20 [ 6.372268] [<ffffffff81e1c075>] sock_init+0x4e/0x59 [ 6.372268] [<ffffffff810001dc>] do_one_initcall+0x3c/0x1a0 [ 6.372268] [<ffffffff81de5767>] kernel_init+0x17a/0x204 [ 6.372268] [<ffffffff81035de4>] kernel_thread_helper+0x4/0x10 [ 6.372268] SOFTIRQ-ON-W at: [ 6.372268] [<ffffffff810b3b73>] __lock_acquire+0x5c3/0x1450 [ 6.372268] [<ffffffff810b4aa6>] lock_acquire+0xa6/0x160 [ 6.372268] [<ffffffff8182bb26>] _raw_spin_lock+0x36/0x70 [ 6.372268] [<ffffffff8116af72>] new_inode+0x52/0xd0 [ 6.372268] [<ffffffff81174a40>] get_sb_pseudo+0xb0/0x180 [ 6.372268] [<ffffffff81735a41>] sockfs_get_sb+0x21/0x30 [ 6.372268] [<ffffffff81152dba>] vfs_kern_mount+0x8a/0x1e0 [ 6.372268] [<ffffffff81152f29>] kern_mount_data+0x19/0x20 [ 6.372268] [<ffffffff81e1c075>] sock_init+0x4e/0x59 [ 6.372268] [<ffffffff810001dc>] do_one_initcall+0x3c/0x1a0 [ 6.372268] [<ffffffff81de5767>] kernel_init+0x17a/0x204 [ 6.372268] [<ffffffff81035de4>] kernel_thread_helper+0x4/0x10 [ 6.372268] INITIAL USE at: [ 6.372268] [<ffffffff810b37e2>] __lock_acquire+0x232/0x1450 [ 6.372268] [<ffffffff810b4aa6>] lock_acquire+0xa6/0x160 [ 6.372268] [<ffffffff8182bb26>] _raw_spin_lock+0x36/0x70 [ 6.372268] [<ffffffff8116af72>] new_inode+0x52/0xd0 [ 6.372268] [<ffffffff81174a40>] get_sb_pseudo+0xb0/0x180 [ 6.372268] [<f [<ffffffff81152dba>] vfs_kern_mount+0x8a/0x1e0 [ 6.372268] [<ffffffff81152f29>] kern_mount_data+0x19/0x20 [ 6.372268] [<ffffffff81e1c075>] sock_init+0x4e/0x59 [ 6.372268] [<ffffffff810001dc>] do_one_initcall+0x3c/0x1a0 [ 6.372268] [<ffffffff81de5767>] kernel_init+0x17a/0x204 [ 6.372268] [<ffffffff81035de4>] kernel_thread_helper+0x4/0x10 [ 6.372268] } [ 6.372268] ... key at: [<ffffffff81bd5bd8>] sock_fs_type+0x58/0x80 [ 6.372268] ... acquired at: [ 6.372268] [<ffffffff810b2940>] check_irq_usage+0x60/0xf0 [ 6.372268] [<ffffffff810b41ff>] __lock_acquire+0xc4f/0x1450 [ 6.372268] [<ffffffff810b4aa6>] lock_acquire+0xa6/0x160 [ 6.372268] [<ffffffff8182bb26>] _raw_spin_lock+0x36/0x70 [ 6.372268] [<ffffffff81736f8c>] socket_get_id+0x3c/0x60 [ 6.372268] [<ffffffff8173b6c3>] sock_i_ino+0x43/0x70 [ 6.372268] [<ffffffff81790fc9>] tcp4_seq_show+0x1a9/0x520 [ 6.372268] [<ffffffff81172005>] seq_read+0x295/0x430 [ 6.372268] [<ffffffff811ad9f4>] proc_reg_read+0x84/0xc0 [ 6.372268] [<ffffffff81150165>] vfs_read+0xb5/0x170 [ 6.372268] [<ffffffff81150274>] sys_read+0x54/0x90 [ 6.372268] [<ffffffff81034ff2>] system_call_fastpath+0x16/0x1b [ 6.372268] [ 6.372268] [ 6.372268] stack backtrace: [ 6.372268] Pid: 2124, comm: pmcd Not tainted 2.6.35-rc5-dgc+ #58 [ 6.372268] Call Trace: [ 6.372268] [<ffffffff810b28d9>] check_usage+0x499/0x4a0 [ 6.372268] [<ffffffff810b24c6>] ? check_usage+0x86/0x4a0 [ 6.372268] [<ffffffff810af729>] ? __bfs+0x129/0x260 [ 6.372268] [<ffffffff810b2940>] check_irq_usage+0x60/0xf0 [ 6.372268] [<ffffffff810b41ff>] __lock_acquire+0xc4f/0x1450 [ 6.372268] [<ffffffff810b4aa6>] lock_acquire+0xa6/0x160 [ 6.372268] [<ffffffff81736f8c>] ? socket_get_id+0x3c/0x60 [ 6.372268] [<ffffffff8182bb26>] _raw_spin_lock+0x36/0x70 [ 6.372268] [<ffffffff81736f8c>] ? socket_get_id+0x3c/0x60 [ 6.372268] [<ffffffff81736f8c>] socket_get_id+0x3c/0x60 [ 6.372268] [<ffffffff8173b6c3>] sock_i_ino+0x43/0x70 [ 6.372268] [<ffffffff81790fc9>] tcp4_seq_show+0x1a9/0x520 [ 6.372268] [<ffffffff81791750>] ? established_get_first+0x60/0x120 [ 6.372268] [<ffffffff8182beb7>] ? _raw_spin_lock_bh+0x67/0x70 [ 6.372268] [<ffffffff81172005>] seq_read+0x295/0x430 [ 6.372268] [<ffffffff81171d70>] ? seq_read+0x0/0x430 [ 6.372268] [<ffffffff811ad9f4>] proc_reg_read+0x84/0xc0 [ 6.372268] [<ffffffff81150165>] vfs_read+0xb5/0x170 [ 6.372268] [<ffffffff81150274>] sys_read+0x54/0x90 [ 6.372268] [<ffffffff81034ff2>] system_call_fastpath+0x16/0x1b -- Dave Chinner david@fromorbit.com -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 76+ messages in thread
* [PATCH 0/2] vfs scalability tree fixes 2010-07-23 11:13 ` Dave Chinner @ 2010-07-23 14:04 ` Dave Chinner -1 siblings, 0 replies; 76+ messages in thread From: Dave Chinner @ 2010-07-23 14:04 UTC (permalink / raw) To: npiggin; +Cc: linux-fsdevel, linux-kernel, linux-mm, fmayhar, johnstul Nick, Here's the fixes I applied to your tree to make the XFS inode cache shrinker build and scan sanely. Cheers, Dave. ^ permalink raw reply [flat|nested] 76+ messages in thread
* [PATCH 0/2] vfs scalability tree fixes @ 2010-07-23 14:04 ` Dave Chinner 0 siblings, 0 replies; 76+ messages in thread From: Dave Chinner @ 2010-07-23 14:04 UTC (permalink / raw) To: npiggin; +Cc: linux-fsdevel, linux-kernel, linux-mm, fmayhar, johnstul Nick, Here's the fixes I applied to your tree to make the XFS inode cache shrinker build and scan sanely. Cheers, Dave. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 0/2] vfs scalability tree fixes 2010-07-23 14:04 ` Dave Chinner @ 2010-07-23 16:09 ` Nick Piggin -1 siblings, 0 replies; 76+ messages in thread From: Nick Piggin @ 2010-07-23 16:09 UTC (permalink / raw) To: Dave Chinner Cc: npiggin, linux-fsdevel, linux-kernel, linux-mm, fmayhar, johnstul On Sat, Jul 24, 2010 at 12:04:00AM +1000, Dave Chinner wrote: > Nick, > > Here's the fixes I applied to your tree to make the XFS inode cache > shrinker build and scan sanely. Thanks for these Dave ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 0/2] vfs scalability tree fixes @ 2010-07-23 16:09 ` Nick Piggin 0 siblings, 0 replies; 76+ messages in thread From: Nick Piggin @ 2010-07-23 16:09 UTC (permalink / raw) To: Dave Chinner Cc: npiggin, linux-fsdevel, linux-kernel, linux-mm, fmayhar, johnstul On Sat, Jul 24, 2010 at 12:04:00AM +1000, Dave Chinner wrote: > Nick, > > Here's the fixes I applied to your tree to make the XFS inode cache > shrinker build and scan sanely. Thanks for these Dave -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 76+ messages in thread
* [PATCH 1/2] xfs: fix shrinker build 2010-07-23 11:13 ` Dave Chinner @ 2010-07-23 14:04 ` Dave Chinner -1 siblings, 0 replies; 76+ messages in thread From: Dave Chinner @ 2010-07-23 14:04 UTC (permalink / raw) To: npiggin; +Cc: linux-fsdevel, linux-kernel, linux-mm, fmayhar, johnstul From: Dave Chinner <dchinner@redhat.com> Remove the stray mount list lock reference from the shrinker code. Signed-off-by: Dave Chinner <dchinner@redhat.com> --- fs/xfs/linux-2.6/xfs_sync.c | 5 +---- 1 files changed, 1 insertions(+), 4 deletions(-) diff --git a/fs/xfs/linux-2.6/xfs_sync.c b/fs/xfs/linux-2.6/xfs_sync.c index 7a5a368..05426bf 100644 --- a/fs/xfs/linux-2.6/xfs_sync.c +++ b/fs/xfs/linux-2.6/xfs_sync.c @@ -916,10 +916,8 @@ xfs_reclaim_inode_shrink( done: nr = shrinker_do_scan(&nr_to_scan, SHRINK_BATCH); - if (!nr) { - up_read(&xfs_mount_list_lock); + if (!nr) return 0; - } xfs_inode_ag_iterator(mp, xfs_reclaim_inode, 0, XFS_ICI_RECLAIM_TAG, 1, &nr); /* if we don't exhaust the scan, don't bother coming back */ @@ -935,7 +933,6 @@ xfs_inode_shrinker_register( struct xfs_mount *mp) { mp->m_inode_shrink.shrink = xfs_reclaim_inode_shrink; - mp->m_inode_shrink.seeks = DEFAULT_SEEKS; register_shrinker(&mp->m_inode_shrink); } -- 1.7.1 ^ permalink raw reply related [flat|nested] 76+ messages in thread
* [PATCH 1/2] xfs: fix shrinker build @ 2010-07-23 14:04 ` Dave Chinner 0 siblings, 0 replies; 76+ messages in thread From: Dave Chinner @ 2010-07-23 14:04 UTC (permalink / raw) To: npiggin; +Cc: linux-fsdevel, linux-kernel, linux-mm, fmayhar, johnstul From: Dave Chinner <dchinner@redhat.com> Remove the stray mount list lock reference from the shrinker code. Signed-off-by: Dave Chinner <dchinner@redhat.com> --- fs/xfs/linux-2.6/xfs_sync.c | 5 +---- 1 files changed, 1 insertions(+), 4 deletions(-) diff --git a/fs/xfs/linux-2.6/xfs_sync.c b/fs/xfs/linux-2.6/xfs_sync.c index 7a5a368..05426bf 100644 --- a/fs/xfs/linux-2.6/xfs_sync.c +++ b/fs/xfs/linux-2.6/xfs_sync.c @@ -916,10 +916,8 @@ xfs_reclaim_inode_shrink( done: nr = shrinker_do_scan(&nr_to_scan, SHRINK_BATCH); - if (!nr) { - up_read(&xfs_mount_list_lock); + if (!nr) return 0; - } xfs_inode_ag_iterator(mp, xfs_reclaim_inode, 0, XFS_ICI_RECLAIM_TAG, 1, &nr); /* if we don't exhaust the scan, don't bother coming back */ @@ -935,7 +933,6 @@ xfs_inode_shrinker_register( struct xfs_mount *mp) { mp->m_inode_shrink.shrink = xfs_reclaim_inode_shrink; - mp->m_inode_shrink.seeks = DEFAULT_SEEKS; register_shrinker(&mp->m_inode_shrink); } -- 1.7.1 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply related [flat|nested] 76+ messages in thread
* [PATCH 2/2] xfs: shrinker should use a per-filesystem scan count 2010-07-23 11:13 ` Dave Chinner @ 2010-07-23 14:04 ` Dave Chinner -1 siblings, 0 replies; 76+ messages in thread From: Dave Chinner @ 2010-07-23 14:04 UTC (permalink / raw) To: npiggin; +Cc: linux-fsdevel, linux-kernel, linux-mm, fmayhar, johnstul From: Dave Chinner <dchinner@redhat.com> The shrinker uses a global static to aggregate excess scan counts. This should be per filesystem like all the other shrinker context to operate correctly. Signed-off-by: Dave Chinner <dchinner@redhat.com> --- fs/xfs/linux-2.6/xfs_sync.c | 5 ++--- fs/xfs/xfs_mount.h | 1 + 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/fs/xfs/linux-2.6/xfs_sync.c b/fs/xfs/linux-2.6/xfs_sync.c index 05426bf..b0e6296 100644 --- a/fs/xfs/linux-2.6/xfs_sync.c +++ b/fs/xfs/linux-2.6/xfs_sync.c @@ -893,7 +893,6 @@ xfs_reclaim_inode_shrink( unsigned long global, gfp_t gfp_mask) { - static unsigned long nr_to_scan; int nr; struct xfs_mount *mp; struct xfs_perag *pag; @@ -908,14 +907,14 @@ xfs_reclaim_inode_shrink( nr_reclaimable += pag->pag_ici_reclaimable; xfs_perag_put(pag); } - shrinker_add_scan(&nr_to_scan, scanned, global, nr_reclaimable, + shrinker_add_scan(&mp->m_shrink_scan_nr, scanned, global, nr_reclaimable, DEFAULT_SEEKS); if (!(gfp_mask & __GFP_FS)) { return 0; } done: - nr = shrinker_do_scan(&nr_to_scan, SHRINK_BATCH); + nr = shrinker_do_scan(&mp->m_shrink_scan_nr, SHRINK_BATCH); if (!nr) return 0; xfs_inode_ag_iterator(mp, xfs_reclaim_inode, 0, diff --git a/fs/xfs/xfs_mount.h b/fs/xfs/xfs_mount.h index 5761087..ed5531f 100644 --- a/fs/xfs/xfs_mount.h +++ b/fs/xfs/xfs_mount.h @@ -260,6 +260,7 @@ typedef struct xfs_mount { __int64_t m_update_flags; /* sb flags we need to update on the next remount,rw */ struct shrinker m_inode_shrink; /* inode reclaim shrinker */ + unsigned long m_shrink_scan_nr; /* shrinker scan count */ } xfs_mount_t; /* -- 1.7.1 ^ permalink raw reply related [flat|nested] 76+ messages in thread
* [PATCH 2/2] xfs: shrinker should use a per-filesystem scan count @ 2010-07-23 14:04 ` Dave Chinner 0 siblings, 0 replies; 76+ messages in thread From: Dave Chinner @ 2010-07-23 14:04 UTC (permalink / raw) To: npiggin; +Cc: linux-fsdevel, linux-kernel, linux-mm, fmayhar, johnstul From: Dave Chinner <dchinner@redhat.com> The shrinker uses a global static to aggregate excess scan counts. This should be per filesystem like all the other shrinker context to operate correctly. Signed-off-by: Dave Chinner <dchinner@redhat.com> --- fs/xfs/linux-2.6/xfs_sync.c | 5 ++--- fs/xfs/xfs_mount.h | 1 + 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/fs/xfs/linux-2.6/xfs_sync.c b/fs/xfs/linux-2.6/xfs_sync.c index 05426bf..b0e6296 100644 --- a/fs/xfs/linux-2.6/xfs_sync.c +++ b/fs/xfs/linux-2.6/xfs_sync.c @@ -893,7 +893,6 @@ xfs_reclaim_inode_shrink( unsigned long global, gfp_t gfp_mask) { - static unsigned long nr_to_scan; int nr; struct xfs_mount *mp; struct xfs_perag *pag; @@ -908,14 +907,14 @@ xfs_reclaim_inode_shrink( nr_reclaimable += pag->pag_ici_reclaimable; xfs_perag_put(pag); } - shrinker_add_scan(&nr_to_scan, scanned, global, nr_reclaimable, + shrinker_add_scan(&mp->m_shrink_scan_nr, scanned, global, nr_reclaimable, DEFAULT_SEEKS); if (!(gfp_mask & __GFP_FS)) { return 0; } done: - nr = shrinker_do_scan(&nr_to_scan, SHRINK_BATCH); + nr = shrinker_do_scan(&mp->m_shrink_scan_nr, SHRINK_BATCH); if (!nr) return 0; xfs_inode_ag_iterator(mp, xfs_reclaim_inode, 0, diff --git a/fs/xfs/xfs_mount.h b/fs/xfs/xfs_mount.h index 5761087..ed5531f 100644 --- a/fs/xfs/xfs_mount.h +++ b/fs/xfs/xfs_mount.h @@ -260,6 +260,7 @@ typedef struct xfs_mount { __int64_t m_update_flags; /* sb flags we need to update on the next remount,rw */ struct shrinker m_inode_shrink; /* inode reclaim shrinker */ + unsigned long m_shrink_scan_nr; /* shrinker scan count */ } xfs_mount_t; /* -- 1.7.1 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply related [flat|nested] 76+ messages in thread
* Re: VFS scalability git tree 2010-07-23 11:13 ` Dave Chinner @ 2010-07-23 15:51 ` Nick Piggin -1 siblings, 0 replies; 76+ messages in thread From: Nick Piggin @ 2010-07-23 15:51 UTC (permalink / raw) To: Dave Chinner Cc: Nick Piggin, linux-fsdevel, linux-kernel, linux-mm, Frank Mayhar, John Stultz On Fri, Jul 23, 2010 at 09:13:10PM +1000, Dave Chinner wrote: > On Fri, Jul 23, 2010 at 05:01:00AM +1000, Nick Piggin wrote: > > I'm pleased to announce I have a git tree up of my vfs scalability work. > > > > git://git.kernel.org/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git > > http://git.kernel.org/?p=linux/kernel/git/npiggin/linux-npiggin.git > > > > Branch vfs-scale-working > > I've got a couple of patches needed to build XFS - they shrinker > merge left some bad fragments - I'll post them in a minute. This OK cool. > email is for the longest ever lockdep warning I've seen that > occurred on boot. Ah thanks. OK that was one of my attempts to keep sockets out of hidding the vfs as much as possible (lazy inode number evaluation). Not a big problem, but I'll drop the patch for now. I have just got one for you too, btw :) (on vanilla kernel but it is messing up my lockdep stress testing on xfs). Real or false? [ INFO: possible circular locking dependency detected ] 2.6.35-rc5-00064-ga9f7f2e #334 ------------------------------------------------------- kswapd0/605 is trying to acquire lock: (&(&ip->i_lock)->mr_lock){++++--}, at: [<ffffffff8125500c>] xfs_ilock+0x7c/0xa0 but task is already holding lock: (&xfs_mount_list_lock){++++.-}, at: [<ffffffff81281a76>] xfs_reclaim_inode_shrink+0xc6/0x140 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&xfs_mount_list_lock){++++.-}: [<ffffffff8106ef9a>] lock_acquire+0x5a/0x70 [<ffffffff815aa646>] _raw_spin_lock+0x36/0x50 [<ffffffff810fabf3>] try_to_free_buffers+0x43/0xb0 [<ffffffff812763b2>] xfs_vm_releasepage+0x92/0xe0 [<ffffffff810908ee>] try_to_release_page+0x2e/0x50 [<ffffffff8109ef56>] shrink_page_list+0x486/0x5a0 [<ffffffff8109f35d>] shrink_inactive_list+0x2ed/0x700 [<ffffffff8109fda0>] shrink_zone+0x3b0/0x460 [<ffffffff810a0f41>] try_to_free_pages+0x241/0x3a0 [<ffffffff810999e2>] __alloc_pages_nodemask+0x4c2/0x6b0 [<ffffffff810c52c6>] alloc_pages_current+0x76/0xf0 [<ffffffff8109205b>] __page_cache_alloc+0xb/0x10 [<ffffffff81092a2a>] find_or_create_page+0x4a/0xa0 [<ffffffff812780cc>] _xfs_buf_lookup_pages+0x14c/0x360 [<ffffffff81279122>] xfs_buf_get+0x72/0x160 [<ffffffff8126eb68>] xfs_trans_get_buf+0xc8/0xf0 [<ffffffff8124439f>] xfs_da_do_buf+0x3df/0x6d0 [<ffffffff81244825>] xfs_da_get_buf+0x25/0x30 [<ffffffff8124a076>] xfs_dir2_data_init+0x46/0xe0 [<ffffffff81247f89>] xfs_dir2_sf_to_block+0xb9/0x5a0 [<ffffffff812501c8>] xfs_dir2_sf_addname+0x418/0x5c0 [<ffffffff81247d7c>] xfs_dir_createname+0x14c/0x1a0 [<ffffffff81271d49>] xfs_create+0x449/0x5d0 [<ffffffff8127d802>] xfs_vn_mknod+0xa2/0x1b0 [<ffffffff8127d92b>] xfs_vn_create+0xb/0x10 [<ffffffff810ddc81>] vfs_create+0x81/0xd0 [<ffffffff810df1a5>] do_last+0x535/0x690 [<ffffffff810e11fd>] do_filp_open+0x21d/0x660 [<ffffffff810d16b4>] do_sys_open+0x64/0x140 [<ffffffff810d17bb>] sys_open+0x1b/0x20 [<ffffffff810023eb>] system_call_fastpath+0x16/0x1b :-> #0 (&(&ip->i_lock)->mr_lock){++++--}: [<ffffffff8106ef10>] __lock_acquire+0x1be0/0x1c10 [<ffffffff8106ef9a>] lock_acquire+0x5a/0x70 [<ffffffff8105dfba>] down_write_nested+0x4a/0x70 [<ffffffff8125500c>] xfs_ilock+0x7c/0xa0 [<ffffffff81280c98>] xfs_reclaim_inode+0x98/0x250 [<ffffffff81281824>] xfs_inode_ag_walk+0x74/0x120 [<ffffffff81281953>] xfs_inode_ag_iterator+0x83/0xe0 [<ffffffff81281aa4>] xfs_reclaim_inode_shrink+0xf4/0x140 [<ffffffff8109ff7d>] shrink_slab+0x12d/0x190 [<ffffffff810a07ad>] balance_pgdat+0x43d/0x6f0 [<ffffffff810a0b1e>] kswapd+0xbe/0x2a0 [<ffffffff810592ae>] kthread+0x8e/0xa0 [<ffffffff81003194>] kernel_thread_helper+0x4/0x10 other info that might help us debug this: 2 locks held by kswapd0/605: #0: (shrinker_rwsem){++++..}, at: [<ffffffff8109fe88>] shrink_slab+0x38/0x190 #1: (&xfs_mount_list_lock){++++.-}, at: [<ffffffff81281a76>] xfs_reclaim_inode_shrink+0xc6/0x140 stack backtrace: Pid: 605, comm: kswapd0 Not tainted 2.6.35-rc5-00064-ga9f7f2e #334 Call Trace: [<ffffffff8106c5d9>] print_circular_bug+0xe9/0xf0 [<ffffffff8106ef10>] __lock_acquire+0x1be0/0x1c10 [<ffffffff8106e3c2>] ? __lock_acquire+0x1092/0x1c10 [<ffffffff8106ef9a>] lock_acquire+0x5a/0x70 [<ffffffff8125500c>] ? xfs_ilock+0x7c/0xa0 [<ffffffff8105dfba>] down_write_nested+0x4a/0x70 [<ffffffff8125500c>] ? xfs_ilock+0x7c/0xa0 [<ffffffff815ae795>] ? sub_preempt_count+0x95/0xd0 [<ffffffff8125500c>] xfs_ilock+0x7c/0xa0 [<ffffffff81280c98>] xfs_reclaim_inode+0x98/0x250 [<ffffffff81281824>] xfs_inode_ag_walk+0x74/0x120 [<ffffffff81280c00>] ? xfs_reclaim_inode+0x0/0x250 [<ffffffff81281953>] xfs_inode_ag_iterator+0x83/0xe0 [<ffffffff81280c00>] ? xfs_reclaim_inode+0x0/0x250 [<ffffffff81281aa4>] xfs_reclaim_inode_shrink+0xf4/0x140 [<ffffffff8109ff7d>] shrink_slab+0x12d/0x190 [<ffffffff810a07ad>] balance_pgdat+0x43d/0x6f0 [<ffffffff810a0b1e>] kswapd+0xbe/0x2a0 [<ffffffff81059700>] ? autoremove_wake_function+0x0/0x40 [<ffffffff815aaf3d>] ? _raw_spin_unlock_irqrestore+0x3d/0x70 [<ffffffff810a0a60>] ? kswapd+0x0/0x2a0 [<ffffffff810592ae>] kthread+0x8e/0xa0 [<ffffffff81003194>] kernel_thread_helper+0x4/0x10 [<ffffffff815ab400>] ? restore_args+0x0/0x30 [<ffffffff81059220>] ? kthread+0x0/0xa0 ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: VFS scalability git tree @ 2010-07-23 15:51 ` Nick Piggin 0 siblings, 0 replies; 76+ messages in thread From: Nick Piggin @ 2010-07-23 15:51 UTC (permalink / raw) To: Dave Chinner Cc: Nick Piggin, linux-fsdevel, linux-kernel, linux-mm, Frank Mayhar, John Stultz On Fri, Jul 23, 2010 at 09:13:10PM +1000, Dave Chinner wrote: > On Fri, Jul 23, 2010 at 05:01:00AM +1000, Nick Piggin wrote: > > I'm pleased to announce I have a git tree up of my vfs scalability work. > > > > git://git.kernel.org/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git > > http://git.kernel.org/?p=linux/kernel/git/npiggin/linux-npiggin.git > > > > Branch vfs-scale-working > > I've got a couple of patches needed to build XFS - they shrinker > merge left some bad fragments - I'll post them in a minute. This OK cool. > email is for the longest ever lockdep warning I've seen that > occurred on boot. Ah thanks. OK that was one of my attempts to keep sockets out of hidding the vfs as much as possible (lazy inode number evaluation). Not a big problem, but I'll drop the patch for now. I have just got one for you too, btw :) (on vanilla kernel but it is messing up my lockdep stress testing on xfs). Real or false? [ INFO: possible circular locking dependency detected ] 2.6.35-rc5-00064-ga9f7f2e #334 ------------------------------------------------------- kswapd0/605 is trying to acquire lock: (&(&ip->i_lock)->mr_lock){++++--}, at: [<ffffffff8125500c>] xfs_ilock+0x7c/0xa0 but task is already holding lock: (&xfs_mount_list_lock){++++.-}, at: [<ffffffff81281a76>] xfs_reclaim_inode_shrink+0xc6/0x140 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&xfs_mount_list_lock){++++.-}: [<ffffffff8106ef9a>] lock_acquire+0x5a/0x70 [<ffffffff815aa646>] _raw_spin_lock+0x36/0x50 [<ffffffff810fabf3>] try_to_free_buffers+0x43/0xb0 [<ffffffff812763b2>] xfs_vm_releasepage+0x92/0xe0 [<ffffffff810908ee>] try_to_release_page+0x2e/0x50 [<ffffffff8109ef56>] shrink_page_list+0x486/0x5a0 [<ffffffff8109f35d>] shrink_inactive_list+0x2ed/0x700 [<ffffffff8109fda0>] shrink_zone+0x3b0/0x460 [<ffffffff810a0f41>] try_to_free_pages+0x241/0x3a0 [<ffffffff810999e2>] __alloc_pages_nodemask+0x4c2/0x6b0 [<ffffffff810c52c6>] alloc_pages_current+0x76/0xf0 [<ffffffff8109205b>] __page_cache_alloc+0xb/0x10 [<ffffffff81092a2a>] find_or_create_page+0x4a/0xa0 [<ffffffff812780cc>] _xfs_buf_lookup_pages+0x14c/0x360 [<ffffffff81279122>] xfs_buf_get+0x72/0x160 [<ffffffff8126eb68>] xfs_trans_get_buf+0xc8/0xf0 [<ffffffff8124439f>] xfs_da_do_buf+0x3df/0x6d0 [<ffffffff81244825>] xfs_da_get_buf+0x25/0x30 [<ffffffff8124a076>] xfs_dir2_data_init+0x46/0xe0 [<ffffffff81247f89>] xfs_dir2_sf_to_block+0xb9/0x5a0 [<ffffffff812501c8>] xfs_dir2_sf_addname+0x418/0x5c0 [<ffffffff81247d7c>] xfs_dir_createname+0x14c/0x1a0 [<ffffffff81271d49>] xfs_create+0x449/0x5d0 [<ffffffff8127d802>] xfs_vn_mknod+0xa2/0x1b0 [<ffffffff8127d92b>] xfs_vn_create+0xb/0x10 [<ffffffff810ddc81>] vfs_create+0x81/0xd0 [<ffffffff810df1a5>] do_last+0x535/0x690 [<ffffffff810e11fd>] do_filp_open+0x21d/0x660 [<ffffffff810d16b4>] do_sys_open+0x64/0x140 [<ffffffff810d17bb>] sys_open+0x1b/0x20 [<ffffffff810023eb>] system_call_fastpath+0x16/0x1b :-> #0 (&(&ip->i_lock)->mr_lock){++++--}: [<ffffffff8106ef10>] __lock_acquire+0x1be0/0x1c10 [<ffffffff8106ef9a>] lock_acquire+0x5a/0x70 [<ffffffff8105dfba>] down_write_nested+0x4a/0x70 [<ffffffff8125500c>] xfs_ilock+0x7c/0xa0 [<ffffffff81280c98>] xfs_reclaim_inode+0x98/0x250 [<ffffffff81281824>] xfs_inode_ag_walk+0x74/0x120 [<ffffffff81281953>] xfs_inode_ag_iterator+0x83/0xe0 [<ffffffff81281aa4>] xfs_reclaim_inode_shrink+0xf4/0x140 [<ffffffff8109ff7d>] shrink_slab+0x12d/0x190 [<ffffffff810a07ad>] balance_pgdat+0x43d/0x6f0 [<ffffffff810a0b1e>] kswapd+0xbe/0x2a0 [<ffffffff810592ae>] kthread+0x8e/0xa0 [<ffffffff81003194>] kernel_thread_helper+0x4/0x10 other info that might help us debug this: 2 locks held by kswapd0/605: #0: (shrinker_rwsem){++++..}, at: [<ffffffff8109fe88>] shrink_slab+0x38/0x190 #1: (&xfs_mount_list_lock){++++.-}, at: [<ffffffff81281a76>] xfs_reclaim_inode_shrink+0xc6/0x140 stack backtrace: Pid: 605, comm: kswapd0 Not tainted 2.6.35-rc5-00064-ga9f7f2e #334 Call Trace: [<ffffffff8106c5d9>] print_circular_bug+0xe9/0xf0 [<ffffffff8106ef10>] __lock_acquire+0x1be0/0x1c10 [<ffffffff8106e3c2>] ? __lock_acquire+0x1092/0x1c10 [<ffffffff8106ef9a>] lock_acquire+0x5a/0x70 [<ffffffff8125500c>] ? xfs_ilock+0x7c/0xa0 [<ffffffff8105dfba>] down_write_nested+0x4a/0x70 [<ffffffff8125500c>] ? xfs_ilock+0x7c/0xa0 [<ffffffff815ae795>] ? sub_preempt_count+0x95/0xd0 [<ffffffff8125500c>] xfs_ilock+0x7c/0xa0 [<ffffffff81280c98>] xfs_reclaim_inode+0x98/0x250 [<ffffffff81281824>] xfs_inode_ag_walk+0x74/0x120 [<ffffffff81280c00>] ? xfs_reclaim_inode+0x0/0x250 [<ffffffff81281953>] xfs_inode_ag_iterator+0x83/0xe0 [<ffffffff81280c00>] ? xfs_reclaim_inode+0x0/0x250 [<ffffffff81281aa4>] xfs_reclaim_inode_shrink+0xf4/0x140 [<ffffffff8109ff7d>] shrink_slab+0x12d/0x190 [<ffffffff810a07ad>] balance_pgdat+0x43d/0x6f0 [<ffffffff810a0b1e>] kswapd+0xbe/0x2a0 [<ffffffff81059700>] ? autoremove_wake_function+0x0/0x40 [<ffffffff815aaf3d>] ? _raw_spin_unlock_irqrestore+0x3d/0x70 [<ffffffff810a0a60>] ? kswapd+0x0/0x2a0 [<ffffffff810592ae>] kthread+0x8e/0xa0 [<ffffffff81003194>] kernel_thread_helper+0x4/0x10 [<ffffffff815ab400>] ? restore_args+0x0/0x30 [<ffffffff81059220>] ? kthread+0x0/0xa0 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: VFS scalability git tree 2010-07-23 15:51 ` Nick Piggin @ 2010-07-24 0:21 ` Dave Chinner -1 siblings, 0 replies; 76+ messages in thread From: Dave Chinner @ 2010-07-24 0:21 UTC (permalink / raw) To: Nick Piggin Cc: linux-fsdevel, linux-kernel, linux-mm, Frank Mayhar, John Stultz On Sat, Jul 24, 2010 at 01:51:18AM +1000, Nick Piggin wrote: > On Fri, Jul 23, 2010 at 09:13:10PM +1000, Dave Chinner wrote: > > On Fri, Jul 23, 2010 at 05:01:00AM +1000, Nick Piggin wrote: > > > I'm pleased to announce I have a git tree up of my vfs scalability work. > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git > > > http://git.kernel.org/?p=linux/kernel/git/npiggin/linux-npiggin.git > > > > > > Branch vfs-scale-working > > > > I've got a couple of patches needed to build XFS - they shrinker > > merge left some bad fragments - I'll post them in a minute. This > > OK cool. > > > > email is for the longest ever lockdep warning I've seen that > > occurred on boot. > > Ah thanks. OK that was one of my attempts to keep sockets out of > hidding the vfs as much as possible (lazy inode number evaluation). > Not a big problem, but I'll drop the patch for now. > > I have just got one for you too, btw :) (on vanilla kernel but it is > messing up my lockdep stress testing on xfs). Real or false? > > [ INFO: possible circular locking dependency detected ] > 2.6.35-rc5-00064-ga9f7f2e #334 > ------------------------------------------------------- > kswapd0/605 is trying to acquire lock: > (&(&ip->i_lock)->mr_lock){++++--}, at: [<ffffffff8125500c>] > xfs_ilock+0x7c/0xa0 > > but task is already holding lock: > (&xfs_mount_list_lock){++++.-}, at: [<ffffffff81281a76>] > xfs_reclaim_inode_shrink+0xc6/0x140 False positive, but the xfs_mount_list_lock is gone in 2.6.35-rc6 - the shrinker context change has fixed that - so you can ignore it anyway. Cheers, Dave. -- Dave Chinner david@fromorbit.com ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: VFS scalability git tree @ 2010-07-24 0:21 ` Dave Chinner 0 siblings, 0 replies; 76+ messages in thread From: Dave Chinner @ 2010-07-24 0:21 UTC (permalink / raw) To: Nick Piggin Cc: linux-fsdevel, linux-kernel, linux-mm, Frank Mayhar, John Stultz On Sat, Jul 24, 2010 at 01:51:18AM +1000, Nick Piggin wrote: > On Fri, Jul 23, 2010 at 09:13:10PM +1000, Dave Chinner wrote: > > On Fri, Jul 23, 2010 at 05:01:00AM +1000, Nick Piggin wrote: > > > I'm pleased to announce I have a git tree up of my vfs scalability work. > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git > > > http://git.kernel.org/?p=linux/kernel/git/npiggin/linux-npiggin.git > > > > > > Branch vfs-scale-working > > > > I've got a couple of patches needed to build XFS - they shrinker > > merge left some bad fragments - I'll post them in a minute. This > > OK cool. > > > > email is for the longest ever lockdep warning I've seen that > > occurred on boot. > > Ah thanks. OK that was one of my attempts to keep sockets out of > hidding the vfs as much as possible (lazy inode number evaluation). > Not a big problem, but I'll drop the patch for now. > > I have just got one for you too, btw :) (on vanilla kernel but it is > messing up my lockdep stress testing on xfs). Real or false? > > [ INFO: possible circular locking dependency detected ] > 2.6.35-rc5-00064-ga9f7f2e #334 > ------------------------------------------------------- > kswapd0/605 is trying to acquire lock: > (&(&ip->i_lock)->mr_lock){++++--}, at: [<ffffffff8125500c>] > xfs_ilock+0x7c/0xa0 > > but task is already holding lock: > (&xfs_mount_list_lock){++++.-}, at: [<ffffffff81281a76>] > xfs_reclaim_inode_shrink+0xc6/0x140 False positive, but the xfs_mount_list_lock is gone in 2.6.35-rc6 - the shrinker context change has fixed that - so you can ignore it anyway. Cheers, Dave. -- Dave Chinner david@fromorbit.com -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: VFS scalability git tree 2010-07-22 19:01 ` Nick Piggin @ 2010-07-23 11:17 ` Christoph Hellwig -1 siblings, 0 replies; 76+ messages in thread From: Christoph Hellwig @ 2010-07-23 11:17 UTC (permalink / raw) To: Nick Piggin Cc: linux-fsdevel, linux-kernel, linux-mm, Frank Mayhar, John Stultz I might sound like a broken record, but if you want to make forward progress with this split it into smaller series. What would be useful for example would be one series each to split the global inode_lock and dcache_lock, without introducing all the fancy new locking primitives, per-bucket locks and lru schemes for a start. ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: VFS scalability git tree @ 2010-07-23 11:17 ` Christoph Hellwig 0 siblings, 0 replies; 76+ messages in thread From: Christoph Hellwig @ 2010-07-23 11:17 UTC (permalink / raw) To: Nick Piggin Cc: linux-fsdevel, linux-kernel, linux-mm, Frank Mayhar, John Stultz I might sound like a broken record, but if you want to make forward progress with this split it into smaller series. What would be useful for example would be one series each to split the global inode_lock and dcache_lock, without introducing all the fancy new locking primitives, per-bucket locks and lru schemes for a start. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: VFS scalability git tree 2010-07-23 11:17 ` Christoph Hellwig @ 2010-07-23 15:42 ` Nick Piggin -1 siblings, 0 replies; 76+ messages in thread From: Nick Piggin @ 2010-07-23 15:42 UTC (permalink / raw) To: Christoph Hellwig Cc: Nick Piggin, linux-fsdevel, linux-kernel, linux-mm, Frank Mayhar, John Stultz On Fri, Jul 23, 2010 at 07:17:46AM -0400, Christoph Hellwig wrote: > I might sound like a broken record, but if you want to make forward > progress with this split it into smaller series. No I appreciate the advice. I put this tree up for people to fetch without posting patches all the time. I think it is important to test and to see the big picture when reviewing the patches, but you are right about how to actually submit patches on the ML. > What would be useful for example would be one series each to split > the global inode_lock and dcache_lock, without introducing all the > fancy new locking primitives, per-bucket locks and lru schemes for > a start. I've kept the series fairly well structured like that. Basically it is in these parts: 1. files lock 2. vfsmount lock 3. mnt refcount 4a. put several new global spinlocks around different parts of dcache 4b. remove dcache_lock after the above protect everything 4c. start doing fine grained locking of hash, inode alias, lru, etc etc 5a, 5b, 5c. same for inodes 6. some further optimisations and cleanups 7. store-free path walking This kind of sequence. I will again try to submit a first couple of things to Al soon. ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: VFS scalability git tree @ 2010-07-23 15:42 ` Nick Piggin 0 siblings, 0 replies; 76+ messages in thread From: Nick Piggin @ 2010-07-23 15:42 UTC (permalink / raw) To: Christoph Hellwig Cc: Nick Piggin, linux-fsdevel, linux-kernel, linux-mm, Frank Mayhar, John Stultz On Fri, Jul 23, 2010 at 07:17:46AM -0400, Christoph Hellwig wrote: > I might sound like a broken record, but if you want to make forward > progress with this split it into smaller series. No I appreciate the advice. I put this tree up for people to fetch without posting patches all the time. I think it is important to test and to see the big picture when reviewing the patches, but you are right about how to actually submit patches on the ML. > What would be useful for example would be one series each to split > the global inode_lock and dcache_lock, without introducing all the > fancy new locking primitives, per-bucket locks and lru schemes for > a start. I've kept the series fairly well structured like that. Basically it is in these parts: 1. files lock 2. vfsmount lock 3. mnt refcount 4a. put several new global spinlocks around different parts of dcache 4b. remove dcache_lock after the above protect everything 4c. start doing fine grained locking of hash, inode alias, lru, etc etc 5a, 5b, 5c. same for inodes 6. some further optimisations and cleanups 7. store-free path walking This kind of sequence. I will again try to submit a first couple of things to Al soon. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: VFS scalability git tree 2010-07-22 19:01 ` Nick Piggin @ 2010-07-23 13:55 ` Dave Chinner -1 siblings, 0 replies; 76+ messages in thread From: Dave Chinner @ 2010-07-23 13:55 UTC (permalink / raw) To: Nick Piggin Cc: linux-fsdevel, linux-kernel, linux-mm, Frank Mayhar, John Stultz On Fri, Jul 23, 2010 at 05:01:00AM +1000, Nick Piggin wrote: > I'm pleased to announce I have a git tree up of my vfs scalability work. > > git://git.kernel.org/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git > http://git.kernel.org/?p=linux/kernel/git/npiggin/linux-npiggin.git > > Branch vfs-scale-working Bug's I've noticed so far: - Using XFS, the existing vfs inode count statistic does not decrease as inodes are free. - the existing vfs dentry count remains at zero - the existing vfs free inode count remains at zero $ pminfo -f vfs.inodes vfs.dentry vfs.inodes.count value 7472612 vfs.inodes.free value 0 vfs.dentry.count value 0 vfs.dentry.free value 0 Performance Summary: With lockdep and CONFIG_XFS_DEBUG enabled, a 16 thread parallel sequential create/unlink workload on an 8p/4GB RAM VM with a virtio block device sitting on a short-stroked 12x2TB SAS array w/ 512MB BBWC in RAID0 via dm and using the noop elevator in the guest VM: $ sudo mkfs.xfs -f -l size=128m -d agcount=16 /dev/vdb meta-data=/dev/vdb isize=256 agcount=16, agsize=1638400 blks = sectsz=512 attr=2 data = bsize=4096 blocks=26214400, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 log =internal log bsize=4096 blocks=32768, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 $ sudo mount -o delaylog,logbsize=262144,nobarrier /dev/vdb /mnt/scratch $ sudo chmod 777 /mnt/scratch $ cd ~/src/fs_mark-3.3/ $ ./fs_mark -S0 -n 500000 -s 0 -d /mnt/scratch/0 -d /mnt/scratch/1 -d /mnt/scratch/3 -d /mnt/scratch/2 -d /mnt/scratch/4 -d /mnt/scratch/5 -d /mnt/scratch/6 -d /mnt/scratch/7 -d /mnt/scratch/8 -d /mnt/scratch/9 -d /mnt/scratch/10 -d /mnt/scratch/11 -d /mnt/scratch/12 -d /mnt/scratch/13 -d /mnt/scratch/14 -d /mnt/scratch/15 files/s 2.6.34-rc4 12550 2.6.35-rc5+scale 12285 So the same within the error margins of the benchmark. Screenshot of monitoring graphs - you can see the effect of the broken stats: http://userweb.kernel.org/~dgc/shrinker-2.6.36/fs_mark-2.6.35-rc4-16x500-xfs.png http://userweb.kernel.org/~dgc/shrinker-2.6.36/fs_mark-2.6.35-rc5-npiggin-scale-lockdep-16x500-xfs.png With a production build (i.e. no lockdep, no xfs debug), I'll run the same fs_mark parallel create/unlink workload to show scalability as I ran here: http://oss.sgi.com/archives/xfs/2010-05/msg00329.html The numbers can't be directly compared, but the test and the setup is the same. The XFS numbers below are with delayed logging enabled. ext4 is using default mkfs and mount parameters except for barrier=0. All numbers are averages of three runs. fs_mark rate (thousands of files/second) 2.6.35-rc5 2.6.35-rc5-scale threads xfs ext4 xfs ext4 1 20 39 20 39 2 35 55 35 57 4 60 41 57 42 8 79 9 75 9 ext4 is getting IO bound at more than 2 threads, so apart from pointing out that XFS is 8-9x faster than ext4 at 8 thread, I'm going to ignore ext4 for the purposes of testing scalability here. For XFS w/ delayed logging, 2.6.35-rc5 is only getting to about 600% CPU and with Nick's patches it's about 650% (10% higher) for slightly lower throughput. So at this class of machine for this workload, the changes result in a slight reduction in scalability. I looked at dbench on XFS as well, but didn't see any significant change in the numbers at up to 200 load threads, so not much to talk about there. Sometime over the weekend I'll build a 16p VM and see what I get from that... Cheers, Dave. -- Dave Chinner david@fromorbit.com ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: VFS scalability git tree @ 2010-07-23 13:55 ` Dave Chinner 0 siblings, 0 replies; 76+ messages in thread From: Dave Chinner @ 2010-07-23 13:55 UTC (permalink / raw) To: Nick Piggin Cc: linux-fsdevel, linux-kernel, linux-mm, Frank Mayhar, John Stultz On Fri, Jul 23, 2010 at 05:01:00AM +1000, Nick Piggin wrote: > I'm pleased to announce I have a git tree up of my vfs scalability work. > > git://git.kernel.org/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git > http://git.kernel.org/?p=linux/kernel/git/npiggin/linux-npiggin.git > > Branch vfs-scale-working Bug's I've noticed so far: - Using XFS, the existing vfs inode count statistic does not decrease as inodes are free. - the existing vfs dentry count remains at zero - the existing vfs free inode count remains at zero $ pminfo -f vfs.inodes vfs.dentry vfs.inodes.count value 7472612 vfs.inodes.free value 0 vfs.dentry.count value 0 vfs.dentry.free value 0 Performance Summary: With lockdep and CONFIG_XFS_DEBUG enabled, a 16 thread parallel sequential create/unlink workload on an 8p/4GB RAM VM with a virtio block device sitting on a short-stroked 12x2TB SAS array w/ 512MB BBWC in RAID0 via dm and using the noop elevator in the guest VM: $ sudo mkfs.xfs -f -l size=128m -d agcount=16 /dev/vdb meta-data=/dev/vdb isize=256 agcount=16, agsize=1638400 blks = sectsz=512 attr=2 data = bsize=4096 blocks=26214400, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 log =internal log bsize=4096 blocks=32768, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 $ sudo mount -o delaylog,logbsize=262144,nobarrier /dev/vdb /mnt/scratch $ sudo chmod 777 /mnt/scratch $ cd ~/src/fs_mark-3.3/ $ ./fs_mark -S0 -n 500000 -s 0 -d /mnt/scratch/0 -d /mnt/scratch/1 -d /mnt/scratch/3 -d /mnt/scratch/2 -d /mnt/scratch/4 -d /mnt/scratch/5 -d /mnt/scratch/6 -d /mnt/scratch/7 -d /mnt/scratch/8 -d /mnt/scratch/9 -d /mnt/scratch/10 -d /mnt/scratch/11 -d /mnt/scratch/12 -d /mnt/scratch/13 -d /mnt/scratch/14 -d /mnt/scratch/15 files/s 2.6.34-rc4 12550 2.6.35-rc5+scale 12285 So the same within the error margins of the benchmark. Screenshot of monitoring graphs - you can see the effect of the broken stats: http://userweb.kernel.org/~dgc/shrinker-2.6.36/fs_mark-2.6.35-rc4-16x500-xfs.png http://userweb.kernel.org/~dgc/shrinker-2.6.36/fs_mark-2.6.35-rc5-npiggin-scale-lockdep-16x500-xfs.png With a production build (i.e. no lockdep, no xfs debug), I'll run the same fs_mark parallel create/unlink workload to show scalability as I ran here: http://oss.sgi.com/archives/xfs/2010-05/msg00329.html The numbers can't be directly compared, but the test and the setup is the same. The XFS numbers below are with delayed logging enabled. ext4 is using default mkfs and mount parameters except for barrier=0. All numbers are averages of three runs. fs_mark rate (thousands of files/second) 2.6.35-rc5 2.6.35-rc5-scale threads xfs ext4 xfs ext4 1 20 39 20 39 2 35 55 35 57 4 60 41 57 42 8 79 9 75 9 ext4 is getting IO bound at more than 2 threads, so apart from pointing out that XFS is 8-9x faster than ext4 at 8 thread, I'm going to ignore ext4 for the purposes of testing scalability here. For XFS w/ delayed logging, 2.6.35-rc5 is only getting to about 600% CPU and with Nick's patches it's about 650% (10% higher) for slightly lower throughput. So at this class of machine for this workload, the changes result in a slight reduction in scalability. I looked at dbench on XFS as well, but didn't see any significant change in the numbers at up to 200 load threads, so not much to talk about there. Sometime over the weekend I'll build a 16p VM and see what I get from that... Cheers, Dave. -- Dave Chinner david@fromorbit.com -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: VFS scalability git tree 2010-07-23 13:55 ` Dave Chinner @ 2010-07-23 16:16 ` Nick Piggin -1 siblings, 0 replies; 76+ messages in thread From: Nick Piggin @ 2010-07-23 16:16 UTC (permalink / raw) To: Dave Chinner Cc: Nick Piggin, linux-fsdevel, linux-kernel, linux-mm, Frank Mayhar, John Stultz On Fri, Jul 23, 2010 at 11:55:14PM +1000, Dave Chinner wrote: > On Fri, Jul 23, 2010 at 05:01:00AM +1000, Nick Piggin wrote: > > I'm pleased to announce I have a git tree up of my vfs scalability work. > > > > git://git.kernel.org/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git > > http://git.kernel.org/?p=linux/kernel/git/npiggin/linux-npiggin.git > > > > Branch vfs-scale-working > > Bug's I've noticed so far: > > - Using XFS, the existing vfs inode count statistic does not decrease > as inodes are free. > - the existing vfs dentry count remains at zero > - the existing vfs free inode count remains at zero > > $ pminfo -f vfs.inodes vfs.dentry > > vfs.inodes.count > value 7472612 > > vfs.inodes.free > value 0 > > vfs.dentry.count > value 0 > > vfs.dentry.free > value 0 Hm, I must have broken it along the way and not noticed. Thanks for pointing that out. > With a production build (i.e. no lockdep, no xfs debug), I'll > run the same fs_mark parallel create/unlink workload to show > scalability as I ran here: > > http://oss.sgi.com/archives/xfs/2010-05/msg00329.html > > The numbers can't be directly compared, but the test and the setup > is the same. The XFS numbers below are with delayed logging > enabled. ext4 is using default mkfs and mount parameters except for > barrier=0. All numbers are averages of three runs. > > fs_mark rate (thousands of files/second) > 2.6.35-rc5 2.6.35-rc5-scale > threads xfs ext4 xfs ext4 > 1 20 39 20 39 > 2 35 55 35 57 > 4 60 41 57 42 > 8 79 9 75 9 > > ext4 is getting IO bound at more than 2 threads, so apart from > pointing out that XFS is 8-9x faster than ext4 at 8 thread, I'm > going to ignore ext4 for the purposes of testing scalability here. > > For XFS w/ delayed logging, 2.6.35-rc5 is only getting to about 600% > CPU and with Nick's patches it's about 650% (10% higher) for > slightly lower throughput. So at this class of machine for this > workload, the changes result in a slight reduction in scalability. That's a good test case, thanks. I'll see if I can find where this is coming from. I will suspect RCU-inodes I suppose. Hm, may have to make them DESTROY_BY_RCU afterall. Thanks, Nick ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: VFS scalability git tree @ 2010-07-23 16:16 ` Nick Piggin 0 siblings, 0 replies; 76+ messages in thread From: Nick Piggin @ 2010-07-23 16:16 UTC (permalink / raw) To: Dave Chinner Cc: Nick Piggin, linux-fsdevel, linux-kernel, linux-mm, Frank Mayhar, John Stultz On Fri, Jul 23, 2010 at 11:55:14PM +1000, Dave Chinner wrote: > On Fri, Jul 23, 2010 at 05:01:00AM +1000, Nick Piggin wrote: > > I'm pleased to announce I have a git tree up of my vfs scalability work. > > > > git://git.kernel.org/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git > > http://git.kernel.org/?p=linux/kernel/git/npiggin/linux-npiggin.git > > > > Branch vfs-scale-working > > Bug's I've noticed so far: > > - Using XFS, the existing vfs inode count statistic does not decrease > as inodes are free. > - the existing vfs dentry count remains at zero > - the existing vfs free inode count remains at zero > > $ pminfo -f vfs.inodes vfs.dentry > > vfs.inodes.count > value 7472612 > > vfs.inodes.free > value 0 > > vfs.dentry.count > value 0 > > vfs.dentry.free > value 0 Hm, I must have broken it along the way and not noticed. Thanks for pointing that out. > With a production build (i.e. no lockdep, no xfs debug), I'll > run the same fs_mark parallel create/unlink workload to show > scalability as I ran here: > > http://oss.sgi.com/archives/xfs/2010-05/msg00329.html > > The numbers can't be directly compared, but the test and the setup > is the same. The XFS numbers below are with delayed logging > enabled. ext4 is using default mkfs and mount parameters except for > barrier=0. All numbers are averages of three runs. > > fs_mark rate (thousands of files/second) > 2.6.35-rc5 2.6.35-rc5-scale > threads xfs ext4 xfs ext4 > 1 20 39 20 39 > 2 35 55 35 57 > 4 60 41 57 42 > 8 79 9 75 9 > > ext4 is getting IO bound at more than 2 threads, so apart from > pointing out that XFS is 8-9x faster than ext4 at 8 thread, I'm > going to ignore ext4 for the purposes of testing scalability here. > > For XFS w/ delayed logging, 2.6.35-rc5 is only getting to about 600% > CPU and with Nick's patches it's about 650% (10% higher) for > slightly lower throughput. So at this class of machine for this > workload, the changes result in a slight reduction in scalability. That's a good test case, thanks. I'll see if I can find where this is coming from. I will suspect RCU-inodes I suppose. Hm, may have to make them DESTROY_BY_RCU afterall. Thanks, Nick -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: VFS scalability git tree 2010-07-23 13:55 ` Dave Chinner @ 2010-07-27 7:05 ` Nick Piggin -1 siblings, 0 replies; 76+ messages in thread From: Nick Piggin @ 2010-07-27 7:05 UTC (permalink / raw) To: Dave Chinner Cc: Nick Piggin, linux-fsdevel, linux-kernel, linux-mm, Frank Mayhar, John Stultz On Fri, Jul 23, 2010 at 11:55:14PM +1000, Dave Chinner wrote: > On Fri, Jul 23, 2010 at 05:01:00AM +1000, Nick Piggin wrote: > > I'm pleased to announce I have a git tree up of my vfs scalability work. > > > > git://git.kernel.org/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git > > http://git.kernel.org/?p=linux/kernel/git/npiggin/linux-npiggin.git > > > > Branch vfs-scale-working > > With a production build (i.e. no lockdep, no xfs debug), I'll > run the same fs_mark parallel create/unlink workload to show > scalability as I ran here: > > http://oss.sgi.com/archives/xfs/2010-05/msg00329.html I've made a similar setup, 2s8c machine, but using 2GB ramdisk instead of a real disk (I don't have easy access to a good disk setup ATM, but I guess we're more interested in code above the block layer anyway). Made an XFS on /dev/ram0 with 16 ags, 64MB log, otherwise same config as yours. I found that performance is a little unstable, so I sync and echo 3 > drop_caches between each run. When it starts reclaiming memory, things get a bit more erratic (and XFS seemed to be almost livelocking for tens of seconds in inode reclaim). So I started with 50 runs of fs_mark -n 20000 (which did not cause reclaim), rebuilding a new filesystem between every run. That gave the following files/sec numbers: N Min Max Median Avg Stddev x 50 100986.4 127622 125013.4 123248.82 5244.1988 + 50 100967.6 135918.6 130214.9 127926.94 6374.6975 Difference at 95.0% confidence 4678.12 +/- 2316.07 3.79567% +/- 1.87919% (Student's t, pooled s = 5836.88) This is 3.8% in favour of vfs-scale-working. I then did 10 runs of -n 20000 but with -L 4 (4 iterations) which did start to fill up memory and cause reclaim during the 2nd and subsequent iterations. N Min Max Median Avg Stddev x 10 116919.7 126785.7 123279.2 122245.17 3169.7993 + 10 110985.1 132440.7 130122.1 126573.41 7151.2947 No difference proven at 95.0% confidence x 10 75820.9 105934.9 79521.7 84263.37 11210.173 + 10 75698.3 115091.7 82932 93022.75 16725.304 No difference proven at 95.0% confidence x 10 66330.5 74950.4 69054.5 69102 2335.615 + 10 68348.5 74231.5 70728.2 70879.45 1838.8345 No difference proven at 95.0% confidence x 10 59353.8 69813.1 67416.7 65164.96 4175.8209 + 10 59670.7 77719.1 74326.1 70966.02 6469.0398 Difference at 95.0% confidence 5801.06 +/- 5115.66 8.90212% +/- 7.85033% (Student's t, pooled s = 5444.54) vfs-scale-working was ahead at every point, but the results were too erratic to read much into it (even the last point I think is questionable). I can provide raw numbers or more details on the setup if required. > enabled. ext4 is using default mkfs and mount parameters except for > barrier=0. All numbers are averages of three runs. > > fs_mark rate (thousands of files/second) > 2.6.35-rc5 2.6.35-rc5-scale > threads xfs ext4 xfs ext4 > 1 20 39 20 39 > 2 35 55 35 57 > 4 60 41 57 42 > 8 79 9 75 9 > > ext4 is getting IO bound at more than 2 threads, so apart from > pointing out that XFS is 8-9x faster than ext4 at 8 thread, I'm > going to ignore ext4 for the purposes of testing scalability here. > > For XFS w/ delayed logging, 2.6.35-rc5 is only getting to about 600% > CPU and with Nick's patches it's about 650% (10% higher) for > slightly lower throughput. So at this class of machine for this > workload, the changes result in a slight reduction in scalability. I wonder if these results are stable. It's possible that changes in reclaim behaviour are causing my patches to require more IO for a given unit of work? I was seeing XFS 'livelock' in reclaim more with my patches, it could be due to more parallelism now being allowed from the vfs and reclaim. Based on my above numbers, I don't see that rcu-inodes is causing a problem, and in terms of SMP scalability, there is really no way that vanilla is more scalable, so I'm interested to see where this slowdown is coming from. > I looked at dbench on XFS as well, but didn't see any significant > change in the numbers at up to 200 load threads, so not much to > talk about there. On a smaller system, dbench doesn't bottleneck too much. It's more of a test to find shared cachelines and such on larger systems when you're talking about several GB/s bandwidths. Thanks, Nick ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: VFS scalability git tree @ 2010-07-27 7:05 ` Nick Piggin 0 siblings, 0 replies; 76+ messages in thread From: Nick Piggin @ 2010-07-27 7:05 UTC (permalink / raw) To: Dave Chinner Cc: Nick Piggin, linux-fsdevel, linux-kernel, linux-mm, Frank Mayhar, John Stultz On Fri, Jul 23, 2010 at 11:55:14PM +1000, Dave Chinner wrote: > On Fri, Jul 23, 2010 at 05:01:00AM +1000, Nick Piggin wrote: > > I'm pleased to announce I have a git tree up of my vfs scalability work. > > > > git://git.kernel.org/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git > > http://git.kernel.org/?p=linux/kernel/git/npiggin/linux-npiggin.git > > > > Branch vfs-scale-working > > With a production build (i.e. no lockdep, no xfs debug), I'll > run the same fs_mark parallel create/unlink workload to show > scalability as I ran here: > > http://oss.sgi.com/archives/xfs/2010-05/msg00329.html I've made a similar setup, 2s8c machine, but using 2GB ramdisk instead of a real disk (I don't have easy access to a good disk setup ATM, but I guess we're more interested in code above the block layer anyway). Made an XFS on /dev/ram0 with 16 ags, 64MB log, otherwise same config as yours. I found that performance is a little unstable, so I sync and echo 3 > drop_caches between each run. When it starts reclaiming memory, things get a bit more erratic (and XFS seemed to be almost livelocking for tens of seconds in inode reclaim). So I started with 50 runs of fs_mark -n 20000 (which did not cause reclaim), rebuilding a new filesystem between every run. That gave the following files/sec numbers: N Min Max Median Avg Stddev x 50 100986.4 127622 125013.4 123248.82 5244.1988 + 50 100967.6 135918.6 130214.9 127926.94 6374.6975 Difference at 95.0% confidence 4678.12 +/- 2316.07 3.79567% +/- 1.87919% (Student's t, pooled s = 5836.88) This is 3.8% in favour of vfs-scale-working. I then did 10 runs of -n 20000 but with -L 4 (4 iterations) which did start to fill up memory and cause reclaim during the 2nd and subsequent iterations. N Min Max Median Avg Stddev x 10 116919.7 126785.7 123279.2 122245.17 3169.7993 + 10 110985.1 132440.7 130122.1 126573.41 7151.2947 No difference proven at 95.0% confidence x 10 75820.9 105934.9 79521.7 84263.37 11210.173 + 10 75698.3 115091.7 82932 93022.75 16725.304 No difference proven at 95.0% confidence x 10 66330.5 74950.4 69054.5 69102 2335.615 + 10 68348.5 74231.5 70728.2 70879.45 1838.8345 No difference proven at 95.0% confidence x 10 59353.8 69813.1 67416.7 65164.96 4175.8209 + 10 59670.7 77719.1 74326.1 70966.02 6469.0398 Difference at 95.0% confidence 5801.06 +/- 5115.66 8.90212% +/- 7.85033% (Student's t, pooled s = 5444.54) vfs-scale-working was ahead at every point, but the results were too erratic to read much into it (even the last point I think is questionable). I can provide raw numbers or more details on the setup if required. > enabled. ext4 is using default mkfs and mount parameters except for > barrier=0. All numbers are averages of three runs. > > fs_mark rate (thousands of files/second) > 2.6.35-rc5 2.6.35-rc5-scale > threads xfs ext4 xfs ext4 > 1 20 39 20 39 > 2 35 55 35 57 > 4 60 41 57 42 > 8 79 9 75 9 > > ext4 is getting IO bound at more than 2 threads, so apart from > pointing out that XFS is 8-9x faster than ext4 at 8 thread, I'm > going to ignore ext4 for the purposes of testing scalability here. > > For XFS w/ delayed logging, 2.6.35-rc5 is only getting to about 600% > CPU and with Nick's patches it's about 650% (10% higher) for > slightly lower throughput. So at this class of machine for this > workload, the changes result in a slight reduction in scalability. I wonder if these results are stable. It's possible that changes in reclaim behaviour are causing my patches to require more IO for a given unit of work? I was seeing XFS 'livelock' in reclaim more with my patches, it could be due to more parallelism now being allowed from the vfs and reclaim. Based on my above numbers, I don't see that rcu-inodes is causing a problem, and in terms of SMP scalability, there is really no way that vanilla is more scalable, so I'm interested to see where this slowdown is coming from. > I looked at dbench on XFS as well, but didn't see any significant > change in the numbers at up to 200 load threads, so not much to > talk about there. On a smaller system, dbench doesn't bottleneck too much. It's more of a test to find shared cachelines and such on larger systems when you're talking about several GB/s bandwidths. Thanks, Nick -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: VFS scalability git tree 2010-07-27 7:05 ` Nick Piggin @ 2010-07-27 8:06 ` Nick Piggin -1 siblings, 0 replies; 76+ messages in thread From: Nick Piggin @ 2010-07-27 8:06 UTC (permalink / raw) To: xfs; +Cc: Dave Chinner, linux-fsdevel On Tue, Jul 27, 2010 at 05:05:39PM +1000, Nick Piggin wrote: > On Fri, Jul 23, 2010 at 11:55:14PM +1000, Dave Chinner wrote: > > On Fri, Jul 23, 2010 at 05:01:00AM +1000, Nick Piggin wrote: > > > I'm pleased to announce I have a git tree up of my vfs scalability work. > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git > > > http://git.kernel.org/?p=linux/kernel/git/npiggin/linux-npiggin.git > > > > > > Branch vfs-scale-working > > > > With a production build (i.e. no lockdep, no xfs debug), I'll > > run the same fs_mark parallel create/unlink workload to show > > scalability as I ran here: > > > > http://oss.sgi.com/archives/xfs/2010-05/msg00329.html > > I've made a similar setup, 2s8c machine, but using 2GB ramdisk instead > of a real disk (I don't have easy access to a good disk setup ATM, but > I guess we're more interested in code above the block layer anyway). > > Made an XFS on /dev/ram0 with 16 ags, 64MB log, otherwise same config as > yours. > > I found that performance is a little unstable, so I sync and echo 3 > > drop_caches between each run. When it starts reclaiming memory, things > get a bit more erratic (and XFS seemed to be almost livelocking for tens > of seconds in inode reclaim). So about this XFS livelock type thingy. It looks like this, and happens periodically while running the above fs_mark benchmark requiring reclaim of inodes: procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 15 0 6900 31032 192 471852 0 0 28 183296 8520 46672 5 91 4 0 19 0 7044 22928 192 466712 96 144 1056 115586 8622 41695 3 96 1 0 19 0 7136 59884 192 471200 160 92 6768 34564 995 542 1 99 0 0 19 0 7244 17008 192 467860 0 104 2068 32953 1044 630 1 99 0 0 18 0 7244 43436 192 467324 0 0 12 0 817 405 0 100 0 0 18 0 7244 43684 192 467324 0 0 0 0 806 425 0 100 0 0 18 0 7244 43932 192 467324 0 0 0 0 808 403 0 100 0 0 18 0 7244 44924 192 467324 0 0 0 0 808 398 0 100 0 0 18 0 7244 45456 192 467324 0 0 0 0 809 409 0 100 0 0 18 0 7244 45472 192 467324 0 0 0 0 805 412 0 100 0 0 18 0 7244 46392 192 467324 0 0 0 0 807 401 0 100 0 0 18 0 7244 47012 192 467324 0 0 0 0 810 414 0 100 0 0 18 0 7244 47260 192 467324 0 0 0 0 806 396 0 100 0 0 18 0 7244 47752 192 467324 0 0 0 0 806 403 0 100 0 0 18 0 7244 48204 192 467324 0 0 0 0 810 409 0 100 0 0 18 0 7244 48608 192 467324 0 0 0 0 807 412 0 100 0 0 18 0 7244 48876 192 467324 0 0 0 0 805 406 0 100 0 0 18 0 7244 49000 192 467324 0 0 0 0 809 402 0 100 0 0 18 0 7244 49408 192 467324 0 0 0 0 807 396 0 100 0 0 18 0 7244 49908 192 467324 0 0 0 0 809 406 0 100 0 0 18 0 7244 50032 192 467324 0 0 0 0 805 404 0 100 0 0 18 0 7244 50032 192 467324 0 0 0 0 805 406 0 100 0 0 19 0 7244 73436 192 467324 0 0 0 6340 808 384 0 100 0 0 20 0 7244 490220 192 467324 0 0 0 8411 830 389 0 100 0 0 18 0 7244 620092 192 467324 0 0 0 4 809 435 0 100 0 0 18 0 7244 620344 192 467324 0 0 0 0 806 430 0 100 0 0 16 0 7244 682620 192 467324 0 0 44 80 890 326 0 100 0 0 12 0 7244 604464 192 479308 76 0 11716 73555 2242 14318 2 94 4 0 12 0 7244 556700 192 483488 0 0 4276 77680 6576 92285 1 97 2 0 17 0 7244 502508 192 485456 0 0 2092 98368 6308 91919 1 96 4 0 11 0 7244 416500 192 487116 0 0 1760 114844 7414 63025 2 96 2 0 Nothing much happening except 100% system time for seconds at a time (length of time varies). This is on a ramdisk, so it isn't waiting for IO. During this time, lots of things are contending on the lock: 60.37% fs_mark [kernel.kallsyms] [k] __write_lock_failed 4.30% kswapd0 [kernel.kallsyms] [k] __write_lock_failed 3.70% fs_mark [kernel.kallsyms] [k] try_wait_for_completion 3.59% fs_mark [kernel.kallsyms] [k] _raw_write_lock 3.46% kswapd1 [kernel.kallsyms] [k] __write_lock_failed | --- __write_lock_failed | |--99.92%-- xfs_inode_ag_walk | xfs_inode_ag_iterator | xfs_reclaim_inode_shrink | shrink_slab | shrink_zone | balance_pgdat | kswapd | kthread | kernel_thread_helper --0.08%-- [...] 3.02% fs_mark [kernel.kallsyms] [k] _raw_spin_lock 1.82% fs_mark [kernel.kallsyms] [k] _xfs_buf_find 1.16% fs_mark [kernel.kallsyms] [k] memcpy 0.86% fs_mark [kernel.kallsyms] [k] _raw_spin_lock_irqsave 0.75% fs_mark [kernel.kallsyms] [k] xfs_log_commit_cil | --- xfs_log_commit_cil _xfs_trans_commit | |--60.00%-- xfs_remove | xfs_vn_unlink | vfs_unlink | do_unlinkat | sys_unlink I'm not sure if there was a long-running read locker in there causing all the write lockers to fail, or if they are just running into one another. But anyway, I hacked the following patch which seemed to improve that behaviour. I haven't run any throughput numbers on it yet, but I could if you're interested (and it's not completely broken!) Batch pag_ici_lock acquisition on the reclaim path, and also skip inodes that appear to be busy to improve locking efficiency. Index: source/fs/xfs/linux-2.6/xfs_sync.c =================================================================== --- source.orig/fs/xfs/linux-2.6/xfs_sync.c 2010-07-26 21:12:11.000000000 +1000 +++ source/fs/xfs/linux-2.6/xfs_sync.c 2010-07-26 21:58:59.000000000 +1000 @@ -87,6 +87,91 @@ xfs_inode_ag_lookup( return ip; } +#define RECLAIM_BATCH_SIZE 32 +STATIC int +xfs_inode_ag_walk_reclaim( + struct xfs_mount *mp, + struct xfs_perag *pag, + int (*execute)(struct xfs_inode *ip, + struct xfs_perag *pag, int flags), + int flags, + int tag, + int exclusive, + int *nr_to_scan) +{ + uint32_t first_index; + int last_error = 0; + int skipped; + xfs_inode_t *batch[RECLAIM_BATCH_SIZE]; + int batchnr; + int i; + + BUG_ON(!exclusive); + +restart: + skipped = 0; + first_index = 0; +next_batch: + batchnr = 0; + /* fill the batch */ + write_lock(&pag->pag_ici_lock); + do { + xfs_inode_t *ip; + + ip = xfs_inode_ag_lookup(mp, pag, &first_index, tag); + if (!ip) + break; + if (!(flags & SYNC_WAIT) && + (!xfs_iflock_free(ip) || + __xfs_iflags_test(ip, XFS_IRECLAIM))) + continue; + + /* + * The radix tree lock here protects a thread in xfs_iget from + * racing with us starting reclaim on the inode. Once we have + * the XFS_IRECLAIM flag set it will not touch us. + */ + spin_lock(&ip->i_flags_lock); + ASSERT_ALWAYS(__xfs_iflags_test(ip, XFS_IRECLAIMABLE)); + if (__xfs_iflags_test(ip, XFS_IRECLAIM)) { + /* ignore as it is already under reclaim */ + spin_unlock(&ip->i_flags_lock); + continue; + } + __xfs_iflags_set(ip, XFS_IRECLAIM); + spin_unlock(&ip->i_flags_lock); + + batch[batchnr++] = ip; + } while ((*nr_to_scan)-- && batchnr < RECLAIM_BATCH_SIZE); + write_unlock(&pag->pag_ici_lock); + + for (i = 0; i < batchnr; i++) { + int error = 0; + xfs_inode_t *ip = batch[i]; + + /* execute doesn't require pag->pag_ici_lock */ + error = execute(ip, pag, flags); + if (error == EAGAIN) { + skipped++; + continue; + } + if (error) + last_error = error; + + /* bail out if the filesystem is corrupted. */ + if (error == EFSCORRUPTED) + break; + } + if (batchnr == RECLAIM_BATCH_SIZE) + goto next_batch; + + if (0 && skipped) { + delay(1); + goto restart; + } + return last_error; +} + STATIC int xfs_inode_ag_walk( struct xfs_mount *mp, @@ -113,6 +198,7 @@ restart: write_lock(&pag->pag_ici_lock); else read_lock(&pag->pag_ici_lock); + ip = xfs_inode_ag_lookup(mp, pag, &first_index, tag); if (!ip) { if (exclusive) @@ -198,8 +284,12 @@ xfs_inode_ag_iterator( nr = nr_to_scan ? *nr_to_scan : INT_MAX; ag = 0; while ((pag = xfs_inode_ag_iter_next_pag(mp, &ag, tag))) { - error = xfs_inode_ag_walk(mp, pag, execute, flags, tag, - exclusive, &nr); + if (tag == XFS_ICI_RECLAIM_TAG) + error = xfs_inode_ag_walk_reclaim(mp, pag, execute, + flags, tag, exclusive, &nr); + else + error = xfs_inode_ag_walk(mp, pag, execute, + flags, tag, exclusive, &nr); xfs_perag_put(pag); if (error) { last_error = error; @@ -789,23 +879,6 @@ xfs_reclaim_inode( { int error = 0; - /* - * The radix tree lock here protects a thread in xfs_iget from racing - * with us starting reclaim on the inode. Once we have the - * XFS_IRECLAIM flag set it will not touch us. - */ - spin_lock(&ip->i_flags_lock); - ASSERT_ALWAYS(__xfs_iflags_test(ip, XFS_IRECLAIMABLE)); - if (__xfs_iflags_test(ip, XFS_IRECLAIM)) { - /* ignore as it is already under reclaim */ - spin_unlock(&ip->i_flags_lock); - write_unlock(&pag->pag_ici_lock); - return 0; - } - __xfs_iflags_set(ip, XFS_IRECLAIM); - spin_unlock(&ip->i_flags_lock); - write_unlock(&pag->pag_ici_lock); - xfs_ilock(ip, XFS_ILOCK_EXCL); if (!xfs_iflock_nowait(ip)) { if (!(sync_mode & SYNC_WAIT)) Index: source/fs/xfs/xfs_inode.h =================================================================== --- source.orig/fs/xfs/xfs_inode.h 2010-07-26 21:10:33.000000000 +1000 +++ source/fs/xfs/xfs_inode.h 2010-07-26 21:11:59.000000000 +1000 @@ -349,6 +349,11 @@ static inline int xfs_iflock_nowait(xfs_ return try_wait_for_completion(&ip->i_flush); } +static inline int xfs_iflock_free(xfs_inode_t *ip) +{ + return completion_done(&ip->i_flush); +} + static inline void xfs_ifunlock(xfs_inode_t *ip) { complete(&ip->i_flush); ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: VFS scalability git tree @ 2010-07-27 8:06 ` Nick Piggin 0 siblings, 0 replies; 76+ messages in thread From: Nick Piggin @ 2010-07-27 8:06 UTC (permalink / raw) To: xfs; +Cc: linux-fsdevel On Tue, Jul 27, 2010 at 05:05:39PM +1000, Nick Piggin wrote: > On Fri, Jul 23, 2010 at 11:55:14PM +1000, Dave Chinner wrote: > > On Fri, Jul 23, 2010 at 05:01:00AM +1000, Nick Piggin wrote: > > > I'm pleased to announce I have a git tree up of my vfs scalability work. > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git > > > http://git.kernel.org/?p=linux/kernel/git/npiggin/linux-npiggin.git > > > > > > Branch vfs-scale-working > > > > With a production build (i.e. no lockdep, no xfs debug), I'll > > run the same fs_mark parallel create/unlink workload to show > > scalability as I ran here: > > > > http://oss.sgi.com/archives/xfs/2010-05/msg00329.html > > I've made a similar setup, 2s8c machine, but using 2GB ramdisk instead > of a real disk (I don't have easy access to a good disk setup ATM, but > I guess we're more interested in code above the block layer anyway). > > Made an XFS on /dev/ram0 with 16 ags, 64MB log, otherwise same config as > yours. > > I found that performance is a little unstable, so I sync and echo 3 > > drop_caches between each run. When it starts reclaiming memory, things > get a bit more erratic (and XFS seemed to be almost livelocking for tens > of seconds in inode reclaim). So about this XFS livelock type thingy. It looks like this, and happens periodically while running the above fs_mark benchmark requiring reclaim of inodes: procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 15 0 6900 31032 192 471852 0 0 28 183296 8520 46672 5 91 4 0 19 0 7044 22928 192 466712 96 144 1056 115586 8622 41695 3 96 1 0 19 0 7136 59884 192 471200 160 92 6768 34564 995 542 1 99 0 0 19 0 7244 17008 192 467860 0 104 2068 32953 1044 630 1 99 0 0 18 0 7244 43436 192 467324 0 0 12 0 817 405 0 100 0 0 18 0 7244 43684 192 467324 0 0 0 0 806 425 0 100 0 0 18 0 7244 43932 192 467324 0 0 0 0 808 403 0 100 0 0 18 0 7244 44924 192 467324 0 0 0 0 808 398 0 100 0 0 18 0 7244 45456 192 467324 0 0 0 0 809 409 0 100 0 0 18 0 7244 45472 192 467324 0 0 0 0 805 412 0 100 0 0 18 0 7244 46392 192 467324 0 0 0 0 807 401 0 100 0 0 18 0 7244 47012 192 467324 0 0 0 0 810 414 0 100 0 0 18 0 7244 47260 192 467324 0 0 0 0 806 396 0 100 0 0 18 0 7244 47752 192 467324 0 0 0 0 806 403 0 100 0 0 18 0 7244 48204 192 467324 0 0 0 0 810 409 0 100 0 0 18 0 7244 48608 192 467324 0 0 0 0 807 412 0 100 0 0 18 0 7244 48876 192 467324 0 0 0 0 805 406 0 100 0 0 18 0 7244 49000 192 467324 0 0 0 0 809 402 0 100 0 0 18 0 7244 49408 192 467324 0 0 0 0 807 396 0 100 0 0 18 0 7244 49908 192 467324 0 0 0 0 809 406 0 100 0 0 18 0 7244 50032 192 467324 0 0 0 0 805 404 0 100 0 0 18 0 7244 50032 192 467324 0 0 0 0 805 406 0 100 0 0 19 0 7244 73436 192 467324 0 0 0 6340 808 384 0 100 0 0 20 0 7244 490220 192 467324 0 0 0 8411 830 389 0 100 0 0 18 0 7244 620092 192 467324 0 0 0 4 809 435 0 100 0 0 18 0 7244 620344 192 467324 0 0 0 0 806 430 0 100 0 0 16 0 7244 682620 192 467324 0 0 44 80 890 326 0 100 0 0 12 0 7244 604464 192 479308 76 0 11716 73555 2242 14318 2 94 4 0 12 0 7244 556700 192 483488 0 0 4276 77680 6576 92285 1 97 2 0 17 0 7244 502508 192 485456 0 0 2092 98368 6308 91919 1 96 4 0 11 0 7244 416500 192 487116 0 0 1760 114844 7414 63025 2 96 2 0 Nothing much happening except 100% system time for seconds at a time (length of time varies). This is on a ramdisk, so it isn't waiting for IO. During this time, lots of things are contending on the lock: 60.37% fs_mark [kernel.kallsyms] [k] __write_lock_failed 4.30% kswapd0 [kernel.kallsyms] [k] __write_lock_failed 3.70% fs_mark [kernel.kallsyms] [k] try_wait_for_completion 3.59% fs_mark [kernel.kallsyms] [k] _raw_write_lock 3.46% kswapd1 [kernel.kallsyms] [k] __write_lock_failed | --- __write_lock_failed | |--99.92%-- xfs_inode_ag_walk | xfs_inode_ag_iterator | xfs_reclaim_inode_shrink | shrink_slab | shrink_zone | balance_pgdat | kswapd | kthread | kernel_thread_helper --0.08%-- [...] 3.02% fs_mark [kernel.kallsyms] [k] _raw_spin_lock 1.82% fs_mark [kernel.kallsyms] [k] _xfs_buf_find 1.16% fs_mark [kernel.kallsyms] [k] memcpy 0.86% fs_mark [kernel.kallsyms] [k] _raw_spin_lock_irqsave 0.75% fs_mark [kernel.kallsyms] [k] xfs_log_commit_cil | --- xfs_log_commit_cil _xfs_trans_commit | |--60.00%-- xfs_remove | xfs_vn_unlink | vfs_unlink | do_unlinkat | sys_unlink I'm not sure if there was a long-running read locker in there causing all the write lockers to fail, or if they are just running into one another. But anyway, I hacked the following patch which seemed to improve that behaviour. I haven't run any throughput numbers on it yet, but I could if you're interested (and it's not completely broken!) Batch pag_ici_lock acquisition on the reclaim path, and also skip inodes that appear to be busy to improve locking efficiency. Index: source/fs/xfs/linux-2.6/xfs_sync.c =================================================================== --- source.orig/fs/xfs/linux-2.6/xfs_sync.c 2010-07-26 21:12:11.000000000 +1000 +++ source/fs/xfs/linux-2.6/xfs_sync.c 2010-07-26 21:58:59.000000000 +1000 @@ -87,6 +87,91 @@ xfs_inode_ag_lookup( return ip; } +#define RECLAIM_BATCH_SIZE 32 +STATIC int +xfs_inode_ag_walk_reclaim( + struct xfs_mount *mp, + struct xfs_perag *pag, + int (*execute)(struct xfs_inode *ip, + struct xfs_perag *pag, int flags), + int flags, + int tag, + int exclusive, + int *nr_to_scan) +{ + uint32_t first_index; + int last_error = 0; + int skipped; + xfs_inode_t *batch[RECLAIM_BATCH_SIZE]; + int batchnr; + int i; + + BUG_ON(!exclusive); + +restart: + skipped = 0; + first_index = 0; +next_batch: + batchnr = 0; + /* fill the batch */ + write_lock(&pag->pag_ici_lock); + do { + xfs_inode_t *ip; + + ip = xfs_inode_ag_lookup(mp, pag, &first_index, tag); + if (!ip) + break; + if (!(flags & SYNC_WAIT) && + (!xfs_iflock_free(ip) || + __xfs_iflags_test(ip, XFS_IRECLAIM))) + continue; + + /* + * The radix tree lock here protects a thread in xfs_iget from + * racing with us starting reclaim on the inode. Once we have + * the XFS_IRECLAIM flag set it will not touch us. + */ + spin_lock(&ip->i_flags_lock); + ASSERT_ALWAYS(__xfs_iflags_test(ip, XFS_IRECLAIMABLE)); + if (__xfs_iflags_test(ip, XFS_IRECLAIM)) { + /* ignore as it is already under reclaim */ + spin_unlock(&ip->i_flags_lock); + continue; + } + __xfs_iflags_set(ip, XFS_IRECLAIM); + spin_unlock(&ip->i_flags_lock); + + batch[batchnr++] = ip; + } while ((*nr_to_scan)-- && batchnr < RECLAIM_BATCH_SIZE); + write_unlock(&pag->pag_ici_lock); + + for (i = 0; i < batchnr; i++) { + int error = 0; + xfs_inode_t *ip = batch[i]; + + /* execute doesn't require pag->pag_ici_lock */ + error = execute(ip, pag, flags); + if (error == EAGAIN) { + skipped++; + continue; + } + if (error) + last_error = error; + + /* bail out if the filesystem is corrupted. */ + if (error == EFSCORRUPTED) + break; + } + if (batchnr == RECLAIM_BATCH_SIZE) + goto next_batch; + + if (0 && skipped) { + delay(1); + goto restart; + } + return last_error; +} + STATIC int xfs_inode_ag_walk( struct xfs_mount *mp, @@ -113,6 +198,7 @@ restart: write_lock(&pag->pag_ici_lock); else read_lock(&pag->pag_ici_lock); + ip = xfs_inode_ag_lookup(mp, pag, &first_index, tag); if (!ip) { if (exclusive) @@ -198,8 +284,12 @@ xfs_inode_ag_iterator( nr = nr_to_scan ? *nr_to_scan : INT_MAX; ag = 0; while ((pag = xfs_inode_ag_iter_next_pag(mp, &ag, tag))) { - error = xfs_inode_ag_walk(mp, pag, execute, flags, tag, - exclusive, &nr); + if (tag == XFS_ICI_RECLAIM_TAG) + error = xfs_inode_ag_walk_reclaim(mp, pag, execute, + flags, tag, exclusive, &nr); + else + error = xfs_inode_ag_walk(mp, pag, execute, + flags, tag, exclusive, &nr); xfs_perag_put(pag); if (error) { last_error = error; @@ -789,23 +879,6 @@ xfs_reclaim_inode( { int error = 0; - /* - * The radix tree lock here protects a thread in xfs_iget from racing - * with us starting reclaim on the inode. Once we have the - * XFS_IRECLAIM flag set it will not touch us. - */ - spin_lock(&ip->i_flags_lock); - ASSERT_ALWAYS(__xfs_iflags_test(ip, XFS_IRECLAIMABLE)); - if (__xfs_iflags_test(ip, XFS_IRECLAIM)) { - /* ignore as it is already under reclaim */ - spin_unlock(&ip->i_flags_lock); - write_unlock(&pag->pag_ici_lock); - return 0; - } - __xfs_iflags_set(ip, XFS_IRECLAIM); - spin_unlock(&ip->i_flags_lock); - write_unlock(&pag->pag_ici_lock); - xfs_ilock(ip, XFS_ILOCK_EXCL); if (!xfs_iflock_nowait(ip)) { if (!(sync_mode & SYNC_WAIT)) Index: source/fs/xfs/xfs_inode.h =================================================================== --- source.orig/fs/xfs/xfs_inode.h 2010-07-26 21:10:33.000000000 +1000 +++ source/fs/xfs/xfs_inode.h 2010-07-26 21:11:59.000000000 +1000 @@ -349,6 +349,11 @@ static inline int xfs_iflock_nowait(xfs_ return try_wait_for_completion(&ip->i_flush); } +static inline int xfs_iflock_free(xfs_inode_t *ip) +{ + return completion_done(&ip->i_flush); +} + static inline void xfs_ifunlock(xfs_inode_t *ip) { complete(&ip->i_flush); _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 76+ messages in thread
* XFS hang in xlog_grant_log_space (was Re: VFS scalability git tree) 2010-07-27 8:06 ` Nick Piggin (?) @ 2010-07-27 11:36 ` Nick Piggin 2010-07-27 13:30 ` Dave Chinner -1 siblings, 1 reply; 76+ messages in thread From: Nick Piggin @ 2010-07-27 11:36 UTC (permalink / raw) To: xfs On Tue, Jul 27, 2010 at 06:06:32PM +1000, Nick Piggin wrote: > On Tue, Jul 27, 2010 at 05:05:39PM +1000, Nick Piggin wrote: > > On Fri, Jul 23, 2010 at 11:55:14PM +1000, Dave Chinner wrote: > > > On Fri, Jul 23, 2010 at 05:01:00AM +1000, Nick Piggin wrote: > > > > I'm pleased to announce I have a git tree up of my vfs scalability work. > > > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git > > > > http://git.kernel.org/?p=linux/kernel/git/npiggin/linux-npiggin.git > > > > > > > > Branch vfs-scale-working > > > > > > With a production build (i.e. no lockdep, no xfs debug), I'll > > > run the same fs_mark parallel create/unlink workload to show > > > scalability as I ran here: > > > > > > http://oss.sgi.com/archives/xfs/2010-05/msg00329.html > > > > I've made a similar setup, 2s8c machine, but using 2GB ramdisk instead > > of a real disk (I don't have easy access to a good disk setup ATM, but > > I guess we're more interested in code above the block layer anyway). > > > > Made an XFS on /dev/ram0 with 16 ags, 64MB log, otherwise same config as > > yours. > > > > I found that performance is a little unstable, so I sync and echo 3 > > > drop_caches between each run. When it starts reclaiming memory, things > > get a bit more erratic (and XFS seemed to be almost livelocking for tens > > of seconds in inode reclaim). On this same system, same setup (vanilla kernel with sha given below), I have now twice reproduced a complete hang in XFS. I can give more information, test patches or options etc if required. setup.sh looks like this: #!/bin/bash modprobe rd rd_size=$[2*1024*1024] dd if=/dev/zero of=/dev/ram0 bs=4K mkfs.xfs -f -l size=64m -d agcount=16 /dev/ram0 mount -o delaylog,logbsize=262144,nobarrier /dev/ram0 mnt The 'dd' is required to ensure rd driver does not allocate pages during IO (which can lead to out of memory deadlocks). Running just involves changing into mnt directory and while true do sync echo 3 > /proc/sys/vm/drop_caches ../dbench -c ../loadfiles/client.txt -t20 8 rm -rf clients done And wait for it to hang (happend in < 5 minutes here) Sysrq of blocked tasks looks like this: Linux version 2.6.35-rc5-00176-gcd5b8f8 (npiggin@amd) (gcc version 4.4.4 (Debian 4.4.4-7) ) #348 SMP Mon Jul 26 22:20:32 EST 2010 brd: module loaded Enabling EXPERIMENTAL delayed logging feature - use at your own risk. XFS mounting filesystem ram0 Ending clean XFS mount for filesystem: ram0 SysRq : Show Blocked State task PC stack pid father flush-1:0 D 00000000fffff8fd 0 2799 2 0x00000000 ffff8800701ff690 0000000000000046 ffff880000000000 ffff8800701fffd8 ffff8800071531f0 00000000000122c0 0000000000004000 ffff8800701fffd8 0000000000004000 00000000000122c0 ffff88007f2d3750 ffff8800071531f0 Call Trace: [<ffffffff812361f8>] xlog_grant_log_space+0x158/0x3d0 [<ffffffff8124a0b5>] ? kmem_zone_zalloc+0x35/0x50 [<ffffffff81034bf0>] ? default_wake_function+0x0/0x10 [<ffffffff8124410c>] ? xfs_trans_ail_push+0x1c/0x80 [<ffffffff81236552>] xfs_log_reserve+0xe2/0xf0 [<ffffffff81243307>] xfs_trans_reserve+0x97/0x200 [<ffffffff8122b637>] ? xfs_iunlock+0x57/0xb0 [<ffffffff8123275b>] xfs_iomap_write_allocate+0x25b/0x3c0 [<ffffffff81232abe>] xfs_iomap+0x1fe/0x270 [<ffffffff8124aaf7>] xfs_map_blocks+0x37/0x40 [<ffffffff8107b8e1>] ? find_lock_page+0x21/0x70 [<ffffffff8124bdca>] xfs_page_state_convert+0x35a/0x690 [<ffffffff8107c38a>] ? find_or_create_page+0x3a/0xa0 [<ffffffff8124c3a6>] xfs_vm_writepage+0x76/0x110 [<ffffffff8108eb00>] ? __dec_zone_page_state+0x30/0x40 [<ffffffff81082c32>] __writepage+0x12/0x40 [<ffffffff81083367>] write_cache_pages+0x1c7/0x3d0 [<ffffffff81082c20>] ? __writepage+0x0/0x40 [<ffffffff8108358f>] generic_writepages+0x1f/0x30 [<ffffffff8124c2fc>] xfs_vm_writepages+0x4c/0x60 [<ffffffff810835bc>] do_writepages+0x1c/0x40 [<ffffffff810d606e>] writeback_single_inode+0xce/0x3b0 [<ffffffff810d6774>] writeback_sb_inodes+0x174/0x260 [<ffffffff810d701f>] writeback_inodes_wb+0x8f/0x180 [<ffffffff810d733b>] wb_writeback+0x22b/0x290 [<ffffffff810d7536>] wb_do_writeback+0x196/0x1a0 [<ffffffff810d7583>] bdi_writeback_task+0x43/0x120 [<ffffffff81050f46>] ? bit_waitqueue+0x16/0xe0 [<ffffffff8108fd00>] ? bdi_start_fn+0x0/0xe0 [<ffffffff8108fd6c>] bdi_start_fn+0x6c/0xe0 [<ffffffff8108fd00>] ? bdi_start_fn+0x0/0xe0 [<ffffffff81050bee>] kthread+0x8e/0xa0 [<ffffffff81003014>] kernel_thread_helper+0x4/0x10 [<ffffffff81050b60>] ? kthread+0x0/0xa0 [<ffffffff81003010>] ? kernel_thread_helper+0x0/0x10 xfssyncd/ram0 D 00000000fffff045 0 2807 2 0x00000000 ffff880007635d00 0000000000000046 ffff880000000000 ffff880007635fd8 ffff880007abd370 00000000000122c0 0000000000004000 ffff880007635fd8 0000000000004000 00000000000122c0 ffff88007f2b7710 ffff880007abd370 Call Trace: [<ffffffff812361f8>] xlog_grant_log_space+0x158/0x3d0 [<ffffffff8124a0b5>] ? kmem_zone_zalloc+0x35/0x50 [<ffffffff81034bf0>] ? default_wake_function+0x0/0x10 [<ffffffff8124410c>] ? xfs_trans_ail_push+0x1c/0x80 [<ffffffff81236552>] xfs_log_reserve+0xe2/0xf0 [<ffffffff81243307>] xfs_trans_reserve+0x97/0x200 [<ffffffff812572b7>] ? xfs_inode_ag_iterator+0x57/0xd0 [<ffffffff81256c0a>] xfs_commit_dummy_trans+0x4a/0xe0 [<ffffffff81257454>] xfs_sync_worker+0x74/0x80 [<ffffffff81256b2a>] xfssyncd+0x13a/0x1d0 [<ffffffff812569f0>] ? xfssyncd+0x0/0x1d0 [<ffffffff81050bee>] kthread+0x8e/0xa0 [<ffffffff81003014>] kernel_thread_helper+0x4/0x10 [<ffffffff81050b60>] ? kthread+0x0/0xa0 [<ffffffff81003010>] ? kernel_thread_helper+0x0/0x10 dbench D 00000000ffffefc6 0 2975 2974 0x00000000 ffff88005ecd1ae8 0000000000000082 ffff880000000000 ffff88005ecd1fd8 ffff8800079ce250 00000000000122c0 0000000000004000 ffff88005ecd1fd8 0000000000004000 00000000000122c0 ffff88007f2d3750 ffff8800079ce250 Call Trace: [<ffffffff812361f8>] xlog_grant_log_space+0x158/0x3d0 [<ffffffff8124a0b5>] ? kmem_zone_zalloc+0x35/0x50 [<ffffffff81034bf0>] ? default_wake_function+0x0/0x10 [<ffffffff8124410c>] ? xfs_trans_ail_push+0x1c/0x80 [<ffffffff81236552>] xfs_log_reserve+0xe2/0xf0 [<ffffffff81243307>] xfs_trans_reserve+0x97/0x200 [<ffffffff81247920>] xfs_create+0x170/0x5d0 [<ffffffff810ca6e2>] ? __d_lookup+0xa2/0x140 [<ffffffff810d0724>] ? mntput_no_expire+0x24/0xe0 [<ffffffff81253202>] xfs_vn_mknod+0xa2/0x1b0 [<ffffffff8125332b>] xfs_vn_create+0xb/0x10 [<ffffffff810c1471>] vfs_create+0x81/0xd0 [<ffffffff810c2915>] do_last+0x515/0x670 [<ffffffff810c48cd>] do_filp_open+0x21d/0x650 [<ffffffff810c6871>] ? filldir+0x71/0xd0 [<ffffffff8103f012>] ? current_fs_time+0x22/0x30 [<ffffffff810ce96b>] ? alloc_fd+0x4b/0x130 [<ffffffff810b5d34>] do_sys_open+0x64/0x140 [<ffffffff810b5bbd>] ? filp_close+0x4d/0x80 [<ffffffff810b5e3b>] sys_open+0x1b/0x20 [<ffffffff810022eb>] system_call_fastpath+0x16/0x1b dbench D 00000000fffff045 0 2976 2974 0x00000000 ffff880060c11b18 0000000000000086 ffff880000000000 ffff880060c11fd8 ffff880007668630 00000000000122c0 0000000000004000 ffff880060c11fd8 0000000000004000 00000000000122c0 ffffffff81793020 ffff880007668630 Call Trace: [<ffffffff81236320>] xlog_grant_log_space+0x280/0x3d0 [<ffffffff81034bf0>] ? default_wake_function+0x0/0x10 [<ffffffff8124410c>] ? xfs_trans_ail_push+0x1c/0x80 [<ffffffff81236552>] xfs_log_reserve+0xe2/0xf0 [<ffffffff81243307>] xfs_trans_reserve+0x97/0x200 [<ffffffff812412c8>] xfs_rename+0x138/0x630 [<ffffffff810c036e>] ? exec_permission+0x3e/0x70 [<ffffffff81253111>] xfs_vn_rename+0x61/0x70 [<ffffffff810c1b4e>] vfs_rename+0x41e/0x480 [<ffffffff810c3bd6>] sys_renameat+0x236/0x270 [<ffffffff8122551d>] ? xfs_dir2_sf_getdents+0x21d/0x390 [<ffffffff810c6800>] ? filldir+0x0/0xd0 [<ffffffff8103f012>] ? current_fs_time+0x22/0x30 [<ffffffff810b8a4a>] ? fput+0x1aa/0x220 [<ffffffff810c3c26>] sys_rename+0x16/0x20 [<ffffffff810022eb>] system_call_fastpath+0x16/0x1b dbench D 00000000ffffeed4 0 2977 2974 0x00000000 ffff88000873fa88 0000000000000082 ffff88000873fac8 ffff88000873ffd8 ffff880007669710 00000000000122c0 0000000000004000 ffff88000873ffd8 0000000000004000 00000000000122c0 ffff88007f2e1790 ffff880007669710 Call Trace: [<ffffffff8155e58d>] schedule_timeout+0x1ad/0x210 [<ffffffff8123dbf6>] ? xfs_icsb_disable_counter+0x16/0xa0 [<ffffffff812445bb>] ? _xfs_trans_bjoin+0x4b/0x60 [<ffffffff8107b5c9>] ? find_get_page+0x19/0xa0 [<ffffffff8123dcb6>] ? xfs_icsb_balance_counter_locked+0x36/0xc0 [<ffffffff8155f4e8>] __down+0x68/0xb0 [<ffffffff81055b0b>] down+0x3b/0x50 [<ffffffff8124d59e>] xfs_buf_lock+0x4e/0x70 [<ffffffff8124ebb3>] _xfs_buf_find+0x133/0x220 [<ffffffff8124ecfb>] xfs_buf_get+0x5b/0x160 [<ffffffff8124ee13>] xfs_buf_read+0x13/0xa0 [<ffffffff81244780>] xfs_trans_read_buf+0x1b0/0x320 [<ffffffff8122922f>] xfs_read_agi+0x6f/0xf0 [<ffffffff8122fa86>] xfs_iunlink+0x46/0x160 [<ffffffff81253d21>] ? xfs_mark_inode_dirty_sync+0x21/0x30 [<ffffffff81253dcf>] ? xfs_ichgtime+0x9f/0xc0 [<ffffffff81245677>] xfs_droplink+0x57/0x70 [<ffffffff8124751a>] xfs_remove+0x28a/0x370 [<ffffffff81253443>] xfs_vn_unlink+0x43/0x90 [<ffffffff810c161b>] vfs_unlink+0x8b/0x110 [<ffffffff810c0e20>] ? lookup_hash+0x30/0x40 [<ffffffff810c3db3>] do_unlinkat+0x183/0x1c0 [<ffffffff810bb3f1>] ? sys_newstat+0x31/0x50 [<ffffffff810c3e01>] sys_unlink+0x11/0x20 [<ffffffff810022eb>] system_call_fastpath+0x16/0x1b dbench D 00000000ffffefa8 0 2978 2974 0x00000000 ffff880040da7c38 0000000000000082 ffff880000000000 ffff880040da7fd8 ffff880007668090 00000000000122c0 0000000000004000 ffff880040da7fd8 0000000000004000 00000000000122c0 ffff88012ff78b90 ffff880007668090 Call Trace: [<ffffffff812361f8>] xlog_grant_log_space+0x158/0x3d0 [<ffffffff8124a0b5>] ? kmem_zone_zalloc+0x35/0x50 [<ffffffff81034bf0>] ? default_wake_function+0x0/0x10 [<ffffffff8124410c>] ? xfs_trans_ail_push+0x1c/0x80 [<ffffffff81236552>] xfs_log_reserve+0xe2/0xf0 [<ffffffff81243307>] xfs_trans_reserve+0x97/0x200 [<ffffffff812495e9>] xfs_setattr+0x7e9/0xad0 [<ffffffff81253766>] xfs_vn_setattr+0x16/0x20 [<ffffffff810cdb94>] notify_change+0x104/0x2e0 [<ffffffff810db270>] utimes_common+0xd0/0x1a0 [<ffffffff810bb64e>] ? sys_newfstat+0x2e/0x40 [<ffffffff810db416>] do_utimes+0xd6/0xf0 [<ffffffff810db5ae>] sys_utime+0x1e/0x70 [<ffffffff810022eb>] system_call_fastpath+0x16/0x1b dbench D 00000000ffffefd3 0 2979 2974 0x00000000 ffff8800072c7ae8 0000000000000082 ffff8800072c7b78 ffff8800072c7fd8 ffff880007669170 00000000000122c0 0000000000004000 ffff8800072c7fd8 0000000000004000 00000000000122c0 ffff88012ff785f0 ffff880007669170 Call Trace: [<ffffffff812361f8>] xlog_grant_log_space+0x158/0x3d0 [<ffffffff8124a0b5>] ? kmem_zone_zalloc+0x35/0x50 [<ffffffff81034bf0>] ? default_wake_function+0x0/0x10 [<ffffffff8124410c>] ? xfs_trans_ail_push+0x1c/0x80 [<ffffffff81236552>] xfs_log_reserve+0xe2/0xf0 [<ffffffff81243307>] xfs_trans_reserve+0x97/0x200 [<ffffffff8122b637>] ? xfs_iunlock+0x57/0xb0 [<ffffffff81247920>] xfs_create+0x170/0x5d0 [<ffffffff810ca6e2>] ? __d_lookup+0xa2/0x140 [<ffffffff81253202>] xfs_vn_mknod+0xa2/0x1b0 [<ffffffff8125332b>] xfs_vn_create+0xb/0x10 [<ffffffff810c1471>] vfs_create+0x81/0xd0 [<ffffffff810c2915>] do_last+0x515/0x670 [<ffffffff810c48cd>] do_filp_open+0x21d/0x650 [<ffffffff810c6871>] ? filldir+0x71/0xd0 [<ffffffff8103f012>] ? current_fs_time+0x22/0x30 [<ffffffff810ce96b>] ? alloc_fd+0x4b/0x130 [<ffffffff810b5d34>] do_sys_open+0x64/0x140 [<ffffffff810b5bbd>] ? filp_close+0x4d/0x80 [<ffffffff810b5e3b>] sys_open+0x1b/0x20 [<ffffffff810022eb>] system_call_fastpath+0x16/0x1b dbench D 00000000ffffeed0 0 2980 2974 0x00000000 ffff88003dd91688 0000000000000082 0000000000000000 ffff88003dd91fd8 ffff880007abc290 00000000000122c0 0000000000004000 ffff88003dd91fd8 0000000000004000 00000000000122c0 ffff88007f2d3750 ffff880007abc290 Call Trace: [<ffffffff8155e58d>] schedule_timeout+0x1ad/0x210 [<ffffffff8155f4e8>] __down+0x68/0xb0 [<ffffffff81055b0b>] down+0x3b/0x50 [<ffffffff8124d59e>] xfs_buf_lock+0x4e/0x70 [<ffffffff8124ebb3>] _xfs_buf_find+0x133/0x220 [<ffffffff8124ecfb>] xfs_buf_get+0x5b/0x160 [<ffffffff8124ee13>] xfs_buf_read+0x13/0xa0 [<ffffffff81244780>] xfs_trans_read_buf+0x1b0/0x320 [<ffffffff8122922f>] xfs_read_agi+0x6f/0xf0 [<ffffffff812292d9>] xfs_ialloc_read_agi+0x29/0x90 [<ffffffff8122957b>] xfs_ialloc_ag_select+0x12b/0x260 [<ffffffff8122abc7>] xfs_dialloc+0x3d7/0x860 [<ffffffff8124acc8>] ? __xfs_get_blocks+0x1c8/0x210 [<ffffffff8107b5c9>] ? find_get_page+0x19/0xa0 [<ffffffff810ddb9e>] ? unmap_underlying_metadata+0xe/0x50 [<ffffffff8122ef4d>] xfs_ialloc+0x5d/0x690 [<ffffffff8124a031>] ? kmem_zone_alloc+0x91/0xe0 [<ffffffff8124570d>] xfs_dir_ialloc+0x7d/0x320 [<ffffffff81236552>] ? xfs_log_reserve+0xe2/0xf0 [<ffffffff81247b83>] xfs_create+0x3d3/0x5d0 [<ffffffff81253202>] xfs_vn_mknod+0xa2/0x1b0 [<ffffffff8125332b>] xfs_vn_create+0xb/0x10 [<ffffffff810c1471>] vfs_create+0x81/0xd0 [<ffffffff810c2915>] do_last+0x515/0x670 [<ffffffff810c48cd>] do_filp_open+0x21d/0x650 [<ffffffff810c6871>] ? filldir+0x71/0xd0 [<ffffffff8103f012>] ? current_fs_time+0x22/0x30 [<ffffffff810ce96b>] ? alloc_fd+0x4b/0x130 [<ffffffff810b5d34>] do_sys_open+0x64/0x140 [<ffffffff810b5bbd>] ? filp_close+0x4d/0x80 [<ffffffff810b5e3b>] sys_open+0x1b/0x20 [<ffffffff810022eb>] system_call_fastpath+0x16/0x1b dbench D 00000000ffffeed0 0 2981 2974 0x00000000 ffff88005b79f618 0000000000000086 ffff88005b79f598 ffff88005b79ffd8 ffff880007abcdd0 00000000000122c0 0000000000004000 ffff88005b79ffd8 0000000000004000 00000000000122c0 ffff88007f2b7710 ffff880007abcdd0 Call Trace: [<ffffffff8155e58d>] schedule_timeout+0x1ad/0x210 [<ffffffff8122cd44>] ? xfs_iext_bno_to_ext+0x84/0x160 [<ffffffff8155f4e8>] __down+0x68/0xb0 [<ffffffff81055b0b>] down+0x3b/0x50 [<ffffffff8124d59e>] xfs_buf_lock+0x4e/0x70 [<ffffffff8124ebb3>] _xfs_buf_find+0x133/0x220 [<ffffffff8124ecfb>] xfs_buf_get+0x5b/0x160 [<ffffffff81244a40>] xfs_trans_get_buf+0xc0/0xe0 [<ffffffff8121ac3f>] xfs_da_do_buf+0x3df/0x6d0 [<ffffffff8121b0c5>] xfs_da_get_buf+0x25/0x30 [<ffffffff81220926>] ? xfs_dir2_data_init+0x46/0xe0 [<ffffffff81220926>] xfs_dir2_data_init+0x46/0xe0 [<ffffffff8121e829>] xfs_dir2_sf_to_block+0xb9/0x5a0 [<ffffffff8105106a>] ? wake_up_bit+0x2a/0x40 [<ffffffff81226a78>] xfs_dir2_sf_addname+0x418/0x5c0 [<ffffffff8122f3fb>] ? xfs_ialloc+0x50b/0x690 [<ffffffff8121e61c>] xfs_dir_createname+0x14c/0x1a0 [<ffffffff81247bf9>] xfs_create+0x449/0x5d0 [<ffffffff81253202>] xfs_vn_mknod+0xa2/0x1b0 [<ffffffff8125332b>] xfs_vn_create+0xb/0x10 [<ffffffff810c1471>] vfs_create+0x81/0xd0 [<ffffffff810c2915>] do_last+0x515/0x670 [<ffffffff810c48cd>] do_filp_open+0x21d/0x650 [<ffffffff810c6871>] ? filldir+0x71/0xd0 [<ffffffff8103f012>] ? current_fs_time+0x22/0x30 [<ffffffff810ce96b>] ? alloc_fd+0x4b/0x130 [<ffffffff810b5d34>] do_sys_open+0x64/0x140 [<ffffffff810b5bbd>] ? filp_close+0x4d/0x80 [<ffffffff810b5e3b>] sys_open+0x1b/0x20 [<ffffffff810022eb>] system_call_fastpath+0x16/0x1b dbench D 00000000ffffefbf 0 2982 2974 0x00000000 ffff88005b7f9c38 0000000000000082 ffff880000000000 ffff88005b7f9fd8 ffff880007698150 00000000000122c0 0000000000004000 ffff88005b7f9fd8 0000000000004000 00000000000122c0 ffff88012ff79130 ffff880007698150 Call Trace: [<ffffffff812361f8>] xlog_grant_log_space+0x158/0x3d0 [<ffffffff8124a0b5>] ? kmem_zone_zalloc+0x35/0x50 [<ffffffff81034bf0>] ? default_wake_function+0x0/0x10 [<ffffffff8124410c>] ? xfs_trans_ail_push+0x1c/0x80 [<ffffffff81236552>] xfs_log_reserve+0xe2/0xf0 [<ffffffff81243307>] xfs_trans_reserve+0x97/0x200 [<ffffffff812495e9>] xfs_setattr+0x7e9/0xad0 [<ffffffff81253766>] xfs_vn_setattr+0x16/0x20 [<ffffffff810cdb94>] notify_change+0x104/0x2e0 [<ffffffff810db270>] utimes_common+0xd0/0x1a0 [<ffffffff810bb64e>] ? sys_newfstat+0x2e/0x40 [<ffffffff810db416>] do_utimes+0xd6/0xf0 [<ffffffff810db5ae>] sys_utime+0x1e/0x70 [<ffffffff810022eb>] system_call_fastpath+0x16/0x1b _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: XFS hang in xlog_grant_log_space (was Re: VFS scalability git tree) 2010-07-27 11:36 ` XFS hang in xlog_grant_log_space (was Re: VFS scalability git tree) Nick Piggin @ 2010-07-27 13:30 ` Dave Chinner 2010-07-27 14:58 ` XFS hang in xlog_grant_log_space Dave Chinner 0 siblings, 1 reply; 76+ messages in thread From: Dave Chinner @ 2010-07-27 13:30 UTC (permalink / raw) To: Nick Piggin; +Cc: xfs On Tue, Jul 27, 2010 at 09:36:26PM +1000, Nick Piggin wrote: > On Tue, Jul 27, 2010 at 06:06:32PM +1000, Nick Piggin wrote: > On this same system, same setup (vanilla kernel with sha given below), > I have now twice reproduced a complete hang in XFS. I can give more > information, test patches or options etc if required. > > setup.sh looks like this: > #!/bin/bash > modprobe rd rd_size=$[2*1024*1024] > dd if=/dev/zero of=/dev/ram0 bs=4K > mkfs.xfs -f -l size=64m -d agcount=16 /dev/ram0 > mount -o delaylog,logbsize=262144,nobarrier /dev/ram0 mnt > > The 'dd' is required to ensure rd driver does not allocate pages > during IO (which can lead to out of memory deadlocks). Running just > involves changing into mnt directory and > > while true > do > sync > echo 3 > /proc/sys/vm/drop_caches > ../dbench -c ../loadfiles/client.txt -t20 8 > rm -rf clients > done > > And wait for it to hang (happend in < 5 minutes here) .... > Call Trace: > [<ffffffff812361f8>] xlog_grant_log_space+0x158/0x3d0 It's waiting on log space to be freed up. Either there's an accounting problem (possible), or you've got an xfslogd/xfsaild spinning and not making progress competing log IOs or pushing the tail of the log. I'll see if I can reproduce it. Cheers, Dave. -- Dave Chinner david@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: XFS hang in xlog_grant_log_space 2010-07-27 13:30 ` Dave Chinner @ 2010-07-27 14:58 ` Dave Chinner 2010-07-28 13:17 ` Dave Chinner 0 siblings, 1 reply; 76+ messages in thread From: Dave Chinner @ 2010-07-27 14:58 UTC (permalink / raw) To: Nick Piggin; +Cc: xfs On Tue, Jul 27, 2010 at 11:30:38PM +1000, Dave Chinner wrote: > On Tue, Jul 27, 2010 at 09:36:26PM +1000, Nick Piggin wrote: > > On Tue, Jul 27, 2010 at 06:06:32PM +1000, Nick Piggin wrote: > > On this same system, same setup (vanilla kernel with sha given below), > > I have now twice reproduced a complete hang in XFS. I can give more > > information, test patches or options etc if required. > > > > setup.sh looks like this: > > #!/bin/bash > > modprobe rd rd_size=$[2*1024*1024] > > dd if=/dev/zero of=/dev/ram0 bs=4K > > mkfs.xfs -f -l size=64m -d agcount=16 /dev/ram0 > > mount -o delaylog,logbsize=262144,nobarrier /dev/ram0 mnt > > > > The 'dd' is required to ensure rd driver does not allocate pages > > during IO (which can lead to out of memory deadlocks). Running just > > involves changing into mnt directory and > > > > while true > > do > > sync > > echo 3 > /proc/sys/vm/drop_caches > > ../dbench -c ../loadfiles/client.txt -t20 8 > > rm -rf clients > > done > > > > And wait for it to hang (happend in < 5 minutes here) > .... > > Call Trace: > > [<ffffffff812361f8>] xlog_grant_log_space+0x158/0x3d0 > > It's waiting on log space to be freed up. Either there's an > accounting problem (possible), or you've got an xfslogd/xfsaild > spinning and not making progress competing log IOs or pushing the > tail of the log. I'll see if I can reproduce it. Ok, I've just reproduced it. From some tracing: touch-3340 [004] 1844935.582716: xfs_log_reserve: dev 1:0 type CREATE t_ocnt 2 t_cnt 2 t_curr_res 167148 t_unit_res 167148 t_flags XLOG_TIC_INITED|XLOG_TIC_PERM_RESERV reserve_headq 0xffff88010f489c78 write_headq 0x(null) grant_reserve_cycle 314 grant_reserve_bytes 24250680 grant_write_cycle 314 grant_write_bytes 24250680 curr_cycle 314 curr_block 44137 tail_cycle 313 tail_block 48532 The key part here is this: curr_cycle 314 curr_block 44137 tail_cycle 313 tail_block 48532 This says the tail of the log is roughly 62MB behind the head. i.e the log is full and we are waiting for tail pushing to write the item holding the tail in place to disk so it can them be moved forward. That's better than an accounting problem, at least. So what is holding the tail in place? The first item on the AIL appears to be: xfsaild/ram0-2997 [000] 1844800.800764: xfs_buf_cond_lock: dev 1:0 bno 0x280120 len 0x2000 hold 3 pincount 0 lock 0 flags ASYNC|DONE|STALE|PAGE_CACHE caller xfs_buf_item_trylock A stale buffer. Given that the next objects show this trace: xfsaild/ram0-2997 [000] 1844800.800767: xfs_ilock_nowait: dev 1:0 ino 0x500241 flags ILOCK_SHARED caller xfs_inode_item_trylock xfsaild/ram0-2997 [000] 1844800.800768: xfs_buf_rele: dev 1:0 bno 0x280120 len 0x2000 hold 4 pincount 0 lock 0 flags ASYNC|DONE|STALE|PAGE_CACHE caller _xfs_buf_find xfsaild/ram0-2997 [000] 1844800.800769: xfs_iunlock: dev 1:0 ino 0x500241 flags ILOCK_SHARED caller xfs_inode_item_pushbuf we see the next item on the AIL is an inode but the trace is followed by a release on the original buffer, than tells me the inode is flush locked and it returned XFS_ITEM_PUSHBUF to push the inode buffer out. That results in xfs_inode_item_pushbuf() being called, and that tries to lock the inode buffer to flush it. xfs_buf_rele is called if the trylock on the buffer fails. IOWs, this looks to be another problem with inode cluster freeing. Ok, so we can't flush the buffer because it is locked. Why is it locked? Well, that is unclear as yet. None of the blocked processes should be holding an inode buffer locked, and a stale buffer should be unlocked during transaction commit and not live longer than the log IO that writes the transaction to disk. That is, it should not get locked again before everything is freed up. That's as much as I can get from post-mortem analysis - I need to capture a trace that spans the lockup to catch what happens to the buffer that we are hung on. That will have to wait until the morning.... Cheers, Dave. -- Dave Chinner david@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: XFS hang in xlog_grant_log_space 2010-07-27 14:58 ` XFS hang in xlog_grant_log_space Dave Chinner @ 2010-07-28 13:17 ` Dave Chinner 2010-07-29 14:05 ` Nick Piggin 0 siblings, 1 reply; 76+ messages in thread From: Dave Chinner @ 2010-07-28 13:17 UTC (permalink / raw) To: Nick Piggin; +Cc: xfs On Wed, Jul 28, 2010 at 12:58:09AM +1000, Dave Chinner wrote: > On Tue, Jul 27, 2010 at 11:30:38PM +1000, Dave Chinner wrote: > > On Tue, Jul 27, 2010 at 09:36:26PM +1000, Nick Piggin wrote: > > > On Tue, Jul 27, 2010 at 06:06:32PM +1000, Nick Piggin wrote: > > > On this same system, same setup (vanilla kernel with sha given below), > > > I have now twice reproduced a complete hang in XFS. I can give more > > > information, test patches or options etc if required. > > > > > > setup.sh looks like this: > > > #!/bin/bash > > > modprobe rd rd_size=$[2*1024*1024] > > > dd if=/dev/zero of=/dev/ram0 bs=4K > > > mkfs.xfs -f -l size=64m -d agcount=16 /dev/ram0 > > > mount -o delaylog,logbsize=262144,nobarrier /dev/ram0 mnt > > > > > > The 'dd' is required to ensure rd driver does not allocate pages > > > during IO (which can lead to out of memory deadlocks). Running just > > > involves changing into mnt directory and > > > > > > while true > > > do > > > sync > > > echo 3 > /proc/sys/vm/drop_caches > > > ../dbench -c ../loadfiles/client.txt -t20 8 > > > rm -rf clients > > > done > > > > > > And wait for it to hang (happend in < 5 minutes here) > > .... > > > Call Trace: > > > [<ffffffff812361f8>] xlog_grant_log_space+0x158/0x3d0 > > > > It's waiting on log space to be freed up. Either there's an > > accounting problem (possible), or you've got an xfslogd/xfsaild > > spinning and not making progress competing log IOs or pushing the > > tail of the log. I'll see if I can reproduce it. > > Ok, I've just reproduced it. From some tracing: > > touch-3340 [004] 1844935.582716: xfs_log_reserve: dev 1:0 type CREATE t_ocnt 2 t_cnt 2 t_curr_res 167148 t_unit_res 167148 t_flags XLOG_TIC_INITED|XLOG_TIC_PERM_RESERV reserve_headq 0xffff88010f489c78 write_headq 0x(null) grant_reserve_cycle 314 grant_reserve_bytes 24250680 grant_write_cycle 314 grant_write_bytes 24250680 curr_cycle 314 curr_block 44137 tail_cycle 313 tail_block 48532 > > The key part here is this: > > curr_cycle 314 curr_block 44137 tail_cycle 313 tail_block 48532 > > This says the tail of the log is roughly 62MB behind the head. i.e > the log is full and we are waiting for tail pushing to write the > item holding the tail in place to disk so it can them be moved > forward. That's better than an accounting problem, at least. > > So what is holding the tail in place? The first item on the AIL > appears to be: > > xfsaild/ram0-2997 [000] 1844800.800764: xfs_buf_cond_lock: dev 1:0 bno 0x280120 len 0x2000 hold 3 pincount 0 lock 0 flags ASYNC|DONE|STALE|PAGE_CACHE caller xfs_buf_item_trylock > > A stale buffer. Given that the next objects show this trace: > > xfsaild/ram0-2997 [000] 1844800.800767: xfs_ilock_nowait: dev 1:0 ino 0x500241 flags ILOCK_SHARED caller xfs_inode_item_trylock > xfsaild/ram0-2997 [000] 1844800.800768: xfs_buf_rele: dev 1:0 bno 0x280120 len 0x2000 hold 4 pincount 0 lock 0 flags ASYNC|DONE|STALE|PAGE_CACHE caller _xfs_buf_find > xfsaild/ram0-2997 [000] 1844800.800769: xfs_iunlock: dev 1:0 ino 0x500241 flags ILOCK_SHARED caller xfs_inode_item_pushbuf > > we see the next item on the AIL is an inode but the trace is > followed by a release on the original buffer, than tells me the > inode is flush locked and it returned XFS_ITEM_PUSHBUF to push the > inode buffer out. That results in xfs_inode_item_pushbuf() being > called, and that tries to lock the inode buffer to flush it. > xfs_buf_rele is called if the trylock on the buffer fails. > > IOWs, this looks to be another problem with inode cluster freeing. > > Ok, so we can't flush the buffer because it is locked. Why is it > locked? Well, that is unclear as yet. None of the blocked processes > should be holding an inode buffer locked, and a stale buffer should > be unlocked during transaction commit and not live longer than > the log IO that writes the transaction to disk. That is, it should > not get locked again before everything is freed up. > > That's as much as I can get from post-mortem analysis - I need to > capture a trace that spans the lockup to catch what happens > to the buffer that we are hung on. That will have to wait until the > morning.... Ok, so I got a trace of all the inode and buffer locking and log item operations, and the reason the hang has occurred can bee seen here: dbench-3084 [007] 1877156.395784: xfs_buf_item_unlock_stale: dev 1:0 bno 0x80040 len 0x2000 hold 2 pincount 0 lock 0 flags |ASYNC|DONE|STALE|PAGE_CACHE recur 1 refcount 1 bliflags |STALE|INODE_ALLOC|STALE_INODE lidesc 0x(null) liflags IN_AIL The key points in this trace is that when we are unlocking a stale buffer during transaction commit - we don't actually unlock it. WHat we do it: /* * If the buf item is marked stale, then don't do anything. We'll * unlock the buffer and free the buf item when the buffer is unpinned * for the last time. */ if (bip->bli_flags & XFS_BLI_STALE) { trace_xfs_buf_item_unlock_stale(bip); ASSERT(bip->bli_format.blf_flags & XFS_BLF_CANCEL); if (!aborted) { atomic_dec(&bip->bli_refcount); return; } } But from the above trace it can be seen that the buffer pincount is zero. Hence it will never get and unpin callback, and hence never get unlocked. As a result, this process here is the one that is stuck on the buffer: dbench D 0000000000000007 0 3084 1 0x00000004 ffff880104e07608 0000000000000086 ffff880104e075b8 0000000000014000 ffff880104e07fd8 0000000000014000 ffff880104e07fd8 ffff880104c1d770 0000000000014000 0000000000014000 ffff880104e07fd8 0000000000014000 Call Trace: [<ffffffff817e59cd>] schedule_timeout+0x1ed/0x2c0 [<ffffffff810de9de>] ? ring_buffer_lock_reserve+0x9e/0x160 [<ffffffff817e690e>] __down+0x7e/0xc0 [<ffffffff812f41d5>] ? _xfs_buf_find+0x145/0x290 [<ffffffff810a05d0>] down+0x40/0x50 [<ffffffff812f41d5>] ? _xfs_buf_find+0x145/0x290 [<ffffffff812f314d>] xfs_buf_lock+0x4d/0x110 [<ffffffff812f41d5>] _xfs_buf_find+0x145/0x290 [<ffffffff812f4380>] xfs_buf_get+0x60/0x1c0 [<ffffffff812ea8f0>] xfs_trans_get_buf+0xe0/0x180 [<ffffffff812ccdab>] xfs_ialloc_inode_init+0xcb/0x1c0 [<ffffffff812cdaf9>] xfs_ialloc_ag_alloc+0x179/0x4a0 [<ffffffff812cdeff>] xfs_dialloc+0xdf/0x870 [<ffffffff8105ec88>] ? pvclock_clocksource_read+0x58/0xd0 [<ffffffff812d2105>] xfs_ialloc+0x65/0x6b0 [<ffffffff812eb032>] xfs_dir_ialloc+0x82/0x2d0 [<ffffffff8128ce83>] ? ftrace_raw_event_xfs_lock_class+0xd3/0xe0 [<ffffffff812ecad7>] ? xfs_create+0x1a7/0x690 [<ffffffff812ecd37>] xfs_create+0x407/0x690 [<ffffffff812f9f97>] xfs_vn_mknod+0xa7/0x1c0 [<ffffffff812fa0e0>] xfs_vn_create+0x10/0x20 [<ffffffff8114ca6c>] vfs_create+0xac/0xd0 [<ffffffff8114d6ec>] do_last+0x51c/0x620 [<ffffffff8114f6d8>] do_filp_open+0x228/0x640 [<ffffffff812c1f18>] ? xfs_dir2_block_getdents+0x218/0x220 [<ffffffff8115a62a>] ? alloc_fd+0x10a/0x150 [<ffffffff8113f919>] do_sys_open+0x69/0x140 [<ffffffff8113fa30>] sys_open+0x20/0x30 [<ffffffff81035032>] system_call_fastpath+0x16/0x1b It is trying to allocate a new inode chunk on disk, which happens to be the one we just removed and staled. Now to find out why the pin count on the buffer is wrong. ..... Now it makes no sense - the buf item pin trace is there directly directly before the above unlock stale trace. The buf item pinning increments both the buffer pin count and the buf item refcount, neith of which are reflected in the unlock stale trace. From the trace analysis I did: process 83 84 85 86 87 ..... get trans_read stale format pin unlock committed unpin stale free trans_get init format pin item unlock get trans_read unlock get trans_read item unlock **** pincount goes from 1 to 0 here without any unpin traces **** get trans_read unlock get trans_read item unlock (repeat 1x) get trans_read unlock get trans_read stale format pin **** no committed/unlock/free trace for this transaction **** **** hold count goes from 2 to 1 without any rele traces **** **** is a new buffer allocated here without the staled buffer being committed? **** trans_get init format pin item unlock get trans_read unlock get trans_read item unlock (repeat 9x) get trans_read unlock get trans_read stale format pin **** pin count does not increment! **** buf lock from xfs_buf_find => hangs **** buffer that was found is locked, not pinned **** Something very strange is happening, and to make matters worse I cannot reproduce it with a debug kernel (ran for 3 hours without failing). Hence it smells like a race condition somewhere. I've reproduced it without delayed logging, so it is not directly related to that functionality. I've seen this warning: Filesystem "ram0": inode 0x704680 background reclaim flush failed with 117 Which indicates we failed to mark an inode stale when freeing an inode cluster, but I think I've fixed that and the problem still shows up. It's posible the last version didn't fix it, but.... Now I've got the ag iterator rotor patch in place as well and possibly a different version of the cluster free fix to what I previously tested and it's now been running for almost half an hour. I can't say yet whether I've fixed the bug of just changed the timing enough to avoid it. I'll leave this test running over night and redo individual patch testing tomorrow. Cheers, Dave. -- Dave Chinner david@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: XFS hang in xlog_grant_log_space 2010-07-28 13:17 ` Dave Chinner @ 2010-07-29 14:05 ` Nick Piggin 2010-07-29 22:56 ` Dave Chinner 0 siblings, 1 reply; 76+ messages in thread From: Nick Piggin @ 2010-07-29 14:05 UTC (permalink / raw) To: Dave Chinner; +Cc: Nick Piggin, xfs On Wed, Jul 28, 2010 at 11:17:44PM +1000, Dave Chinner wrote: > Something very strange is happening, and to make matters worse I > cannot reproduce it with a debug kernel (ran for 3 hours without > failing). Hence it smells like a race condition somewhere. > > I've reproduced it without delayed logging, so it is not directly > related to that functionality. > > I've seen this warning: > > Filesystem "ram0": inode 0x704680 background reclaim flush failed with 117 > > Which indicates we failed to mark an inode stale when freeing an > inode cluster, but I think I've fixed that and the problem still > shows up. It's posible the last version didn't fix it, but.... I've seen that one a couple of times too. Keeps coming back each time you echo 3 > /proc/sys/vm/drop_caches :) > Now I've got the ag iterator rotor patch in place as well and > possibly a different version of the cluster free fix to what I > previously tested and it's now been running for almost half an hour. > I can't say yet whether I've fixed the bug of just changed the > timing enough to avoid it. I'll leave this test running over night > and redo individual patch testing tomorrow. I reproduced it with fs_stress now too. Any patches I could test for you just let me know. _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: XFS hang in xlog_grant_log_space 2010-07-29 14:05 ` Nick Piggin @ 2010-07-29 22:56 ` Dave Chinner 2010-07-30 3:59 ` Nick Piggin 0 siblings, 1 reply; 76+ messages in thread From: Dave Chinner @ 2010-07-29 22:56 UTC (permalink / raw) To: Nick Piggin; +Cc: Nick Piggin, xfs On Fri, Jul 30, 2010 at 12:05:46AM +1000, Nick Piggin wrote: > On Wed, Jul 28, 2010 at 11:17:44PM +1000, Dave Chinner wrote: > > Something very strange is happening, and to make matters worse I > > cannot reproduce it with a debug kernel (ran for 3 hours without > > failing). Hence it smells like a race condition somewhere. > > > > I've reproduced it without delayed logging, so it is not directly > > related to that functionality. > > > > I've seen this warning: > > > > Filesystem "ram0": inode 0x704680 background reclaim flush failed with 117 > > > > Which indicates we failed to mark an inode stale when freeing an > > inode cluster, but I think I've fixed that and the problem still > > shows up. It's posible the last version didn't fix it, but.... > > I've seen that one a couple of times too. Keeps coming back each > time you echo 3 > /proc/sys/vm/drop_caches :) Yup - it's an unflushable inode that is pinning the tail of the log, hence causing the log space hangs. > > Now I've got the ag iterator rotor patch in place as well and > > possibly a different version of the cluster free fix to what I > > previously tested and it's now been running for almost half an hour. > > I can't say yet whether I've fixed the bug of just changed the > > timing enough to avoid it. I'll leave this test running over night > > and redo individual patch testing tomorrow. > > I reproduced it with fs_stress now too. Any patches I could test > for you just let me know. You should see them in a few minutes ;) Cheers, Dave. -- Dave Chinner david@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: XFS hang in xlog_grant_log_space 2010-07-29 22:56 ` Dave Chinner @ 2010-07-30 3:59 ` Nick Piggin 0 siblings, 0 replies; 76+ messages in thread From: Nick Piggin @ 2010-07-30 3:59 UTC (permalink / raw) To: Dave Chinner; +Cc: Nick Piggin, Nick Piggin, xfs On Fri, Jul 30, 2010 at 08:56:58AM +1000, Dave Chinner wrote: > On Fri, Jul 30, 2010 at 12:05:46AM +1000, Nick Piggin wrote: > > On Wed, Jul 28, 2010 at 11:17:44PM +1000, Dave Chinner wrote: > > > Something very strange is happening, and to make matters worse I > > > cannot reproduce it with a debug kernel (ran for 3 hours without > > > failing). Hence it smells like a race condition somewhere. > > > > > > I've reproduced it without delayed logging, so it is not directly > > > related to that functionality. > > > > > > I've seen this warning: > > > > > > Filesystem "ram0": inode 0x704680 background reclaim flush failed with 117 > > > > > > Which indicates we failed to mark an inode stale when freeing an > > > inode cluster, but I think I've fixed that and the problem still > > > shows up. It's posible the last version didn't fix it, but.... > > > > I've seen that one a couple of times too. Keeps coming back each > > time you echo 3 > /proc/sys/vm/drop_caches :) > > Yup - it's an unflushable inode that is pinning the tail of the log, > hence causing the log space hangs. > > > > Now I've got the ag iterator rotor patch in place as well and > > > possibly a different version of the cluster free fix to what I > > > previously tested and it's now been running for almost half an hour. > > > I can't say yet whether I've fixed the bug of just changed the > > > timing enough to avoid it. I'll leave this test running over night > > > and redo individual patch testing tomorrow. > > > > I reproduced it with fs_stress now too. Any patches I could test > > for you just let me know. > > You should see them in a few minutes ;) It's certainly not locking up like it used to... Thanks! _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: VFS scalability git tree 2010-07-27 8:06 ` Nick Piggin @ 2010-07-28 12:57 ` Dave Chinner -1 siblings, 0 replies; 76+ messages in thread From: Dave Chinner @ 2010-07-28 12:57 UTC (permalink / raw) To: Nick Piggin; +Cc: xfs, linux-fsdevel On Tue, Jul 27, 2010 at 06:06:32PM +1000, Nick Piggin wrote: > On Tue, Jul 27, 2010 at 05:05:39PM +1000, Nick Piggin wrote: > > On Fri, Jul 23, 2010 at 11:55:14PM +1000, Dave Chinner wrote: > > > On Fri, Jul 23, 2010 at 05:01:00AM +1000, Nick Piggin wrote: > > > > I'm pleased to announce I have a git tree up of my vfs scalability work. > > > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git > > > > http://git.kernel.org/?p=linux/kernel/git/npiggin/linux-npiggin.git > > > > > > > > Branch vfs-scale-working > > > > > > With a production build (i.e. no lockdep, no xfs debug), I'll > > > run the same fs_mark parallel create/unlink workload to show > > > scalability as I ran here: > > > > > > http://oss.sgi.com/archives/xfs/2010-05/msg00329.html > > > > I've made a similar setup, 2s8c machine, but using 2GB ramdisk instead > > of a real disk (I don't have easy access to a good disk setup ATM, but > > I guess we're more interested in code above the block layer anyway). > > > > Made an XFS on /dev/ram0 with 16 ags, 64MB log, otherwise same config as > > yours. > > > > I found that performance is a little unstable, so I sync and echo 3 > > > drop_caches between each run. When it starts reclaiming memory, things > > get a bit more erratic (and XFS seemed to be almost livelocking for tens > > of seconds in inode reclaim). > > So about this XFS livelock type thingy. It looks like this, and happens > periodically while running the above fs_mark benchmark requiring reclaim > of inodes: .... > Nothing much happening except 100% system time for seconds at a time > (length of time varies). This is on a ramdisk, so it isn't waiting > for IO. > > During this time, lots of things are contending on the lock: > > 60.37% fs_mark [kernel.kallsyms] [k] __write_lock_failed > 4.30% kswapd0 [kernel.kallsyms] [k] __write_lock_failed > 3.70% fs_mark [kernel.kallsyms] [k] try_wait_for_completion > 3.59% fs_mark [kernel.kallsyms] [k] _raw_write_lock > 3.46% kswapd1 [kernel.kallsyms] [k] __write_lock_failed > | > --- __write_lock_failed > | > |--99.92%-- xfs_inode_ag_walk > | xfs_inode_ag_iterator > | xfs_reclaim_inode_shrink > | shrink_slab > | shrink_zone > | balance_pgdat > | kswapd > | kthread > | kernel_thread_helper > --0.08%-- [...] > > 3.02% fs_mark [kernel.kallsyms] [k] _raw_spin_lock > 1.82% fs_mark [kernel.kallsyms] [k] _xfs_buf_find > 1.16% fs_mark [kernel.kallsyms] [k] memcpy > 0.86% fs_mark [kernel.kallsyms] [k] _raw_spin_lock_irqsave > 0.75% fs_mark [kernel.kallsyms] [k] xfs_log_commit_cil > | > --- xfs_log_commit_cil > _xfs_trans_commit > | > |--60.00%-- xfs_remove > | xfs_vn_unlink > | vfs_unlink > | do_unlinkat > | sys_unlink > > I'm not sure if there was a long-running read locker in there causing > all the write lockers to fail, or if they are just running into one > another. The longest hold is in the inode cluster writeback (xfs_iflush_cluster), but if there is no IO then I don't see how that would be a problem. I suspect that it might be caused by having several CPUs all trying to run the shrinker at the same time and them all starting at the same AG and therefore lockstepping and getting nothing done because they are all scanning the same inodes. Maybe a start AG rotor for xfs_inode_ag_iterator() is needed to avoid this lockstepping. I've attached a patch below to do this - can you give it a try? > But anyway, I hacked the following patch which seemed to > improve that behaviour. I haven't run any throughput numbers on it yet, > but I could if you're interested (and it's not completely broken!) Batching is certainly something that I have been considering, but apart from the excessive scanning bug, the per-ag inode tree lookups hve not featured prominently in any profiling I've done, so it hasn't been a high priority. You patch looks like it will work fine, but I think it can be made a lot cleaner. I'll have a closer look at this once I get to the bottom of the dbench hang you are seeing.... Cheers, Dave. -- Dave Chinner david@fromorbit.com xfs: add an AG iterator start rotor From: Dave Chinner <dchinner@redhat.com> To avoid multiple CPUs from executing inode cache shrinkers on the same AG all at the same time, make every shrinker call start on a different AG. This will mostly prevent concurrent shrinker calls from competing for the serialising pag_ici_lock and lock-stepping reclaim. Signed-off-by: Dave Chinner <dchinner@redhat.com> --- fs/xfs/linux-2.6/xfs_sync.c | 11 ++++++++++- fs/xfs/xfs_mount.h | 1 + 2 files changed, 11 insertions(+), 1 deletions(-) diff --git a/fs/xfs/linux-2.6/xfs_sync.c b/fs/xfs/linux-2.6/xfs_sync.c index dfcbd98..5322105 100644 --- a/fs/xfs/linux-2.6/xfs_sync.c +++ b/fs/xfs/linux-2.6/xfs_sync.c @@ -181,11 +181,14 @@ xfs_inode_ag_iterator( struct xfs_perag *pag; int error = 0; int last_error = 0; + xfs_agnumber_t start_ag; xfs_agnumber_t ag; int nr; + int looped = 0; nr = nr_to_scan ? *nr_to_scan : INT_MAX; - ag = 0; + start_ag = atomic_inc_return(&mp->m_agiter_rotor) & mp->m_sb.sb_agcount; + ag = start_ag; while ((pag = xfs_inode_ag_iter_next_pag(mp, &ag, tag))) { error = xfs_inode_ag_walk(mp, pag, execute, flags, tag, exclusive, &nr); @@ -197,6 +200,12 @@ xfs_inode_ag_iterator( } if (nr <= 0) break; + if (ag >= mp->m_sb.sb_agcount) { + looped = 1; + ag = 0; + } + if (ag >= start_ag && looped) + break; } if (nr_to_scan) *nr_to_scan = nr; diff --git a/fs/xfs/xfs_mount.h b/fs/xfs/xfs_mount.h index 622da21..fae61bb 100644 --- a/fs/xfs/xfs_mount.h +++ b/fs/xfs/xfs_mount.h @@ -199,6 +199,7 @@ typedef struct xfs_mount { __int64_t m_update_flags; /* sb flags we need to update on the next remount,rw */ struct shrinker m_inode_shrink; /* inode reclaim shrinker */ + atomic_t m_agiter_rotor; /* ag iterator start rotor */ } xfs_mount_t; /* ^ permalink raw reply related [flat|nested] 76+ messages in thread
* Re: VFS scalability git tree @ 2010-07-28 12:57 ` Dave Chinner 0 siblings, 0 replies; 76+ messages in thread From: Dave Chinner @ 2010-07-28 12:57 UTC (permalink / raw) To: Nick Piggin; +Cc: linux-fsdevel, xfs On Tue, Jul 27, 2010 at 06:06:32PM +1000, Nick Piggin wrote: > On Tue, Jul 27, 2010 at 05:05:39PM +1000, Nick Piggin wrote: > > On Fri, Jul 23, 2010 at 11:55:14PM +1000, Dave Chinner wrote: > > > On Fri, Jul 23, 2010 at 05:01:00AM +1000, Nick Piggin wrote: > > > > I'm pleased to announce I have a git tree up of my vfs scalability work. > > > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git > > > > http://git.kernel.org/?p=linux/kernel/git/npiggin/linux-npiggin.git > > > > > > > > Branch vfs-scale-working > > > > > > With a production build (i.e. no lockdep, no xfs debug), I'll > > > run the same fs_mark parallel create/unlink workload to show > > > scalability as I ran here: > > > > > > http://oss.sgi.com/archives/xfs/2010-05/msg00329.html > > > > I've made a similar setup, 2s8c machine, but using 2GB ramdisk instead > > of a real disk (I don't have easy access to a good disk setup ATM, but > > I guess we're more interested in code above the block layer anyway). > > > > Made an XFS on /dev/ram0 with 16 ags, 64MB log, otherwise same config as > > yours. > > > > I found that performance is a little unstable, so I sync and echo 3 > > > drop_caches between each run. When it starts reclaiming memory, things > > get a bit more erratic (and XFS seemed to be almost livelocking for tens > > of seconds in inode reclaim). > > So about this XFS livelock type thingy. It looks like this, and happens > periodically while running the above fs_mark benchmark requiring reclaim > of inodes: .... > Nothing much happening except 100% system time for seconds at a time > (length of time varies). This is on a ramdisk, so it isn't waiting > for IO. > > During this time, lots of things are contending on the lock: > > 60.37% fs_mark [kernel.kallsyms] [k] __write_lock_failed > 4.30% kswapd0 [kernel.kallsyms] [k] __write_lock_failed > 3.70% fs_mark [kernel.kallsyms] [k] try_wait_for_completion > 3.59% fs_mark [kernel.kallsyms] [k] _raw_write_lock > 3.46% kswapd1 [kernel.kallsyms] [k] __write_lock_failed > | > --- __write_lock_failed > | > |--99.92%-- xfs_inode_ag_walk > | xfs_inode_ag_iterator > | xfs_reclaim_inode_shrink > | shrink_slab > | shrink_zone > | balance_pgdat > | kswapd > | kthread > | kernel_thread_helper > --0.08%-- [...] > > 3.02% fs_mark [kernel.kallsyms] [k] _raw_spin_lock > 1.82% fs_mark [kernel.kallsyms] [k] _xfs_buf_find > 1.16% fs_mark [kernel.kallsyms] [k] memcpy > 0.86% fs_mark [kernel.kallsyms] [k] _raw_spin_lock_irqsave > 0.75% fs_mark [kernel.kallsyms] [k] xfs_log_commit_cil > | > --- xfs_log_commit_cil > _xfs_trans_commit > | > |--60.00%-- xfs_remove > | xfs_vn_unlink > | vfs_unlink > | do_unlinkat > | sys_unlink > > I'm not sure if there was a long-running read locker in there causing > all the write lockers to fail, or if they are just running into one > another. The longest hold is in the inode cluster writeback (xfs_iflush_cluster), but if there is no IO then I don't see how that would be a problem. I suspect that it might be caused by having several CPUs all trying to run the shrinker at the same time and them all starting at the same AG and therefore lockstepping and getting nothing done because they are all scanning the same inodes. Maybe a start AG rotor for xfs_inode_ag_iterator() is needed to avoid this lockstepping. I've attached a patch below to do this - can you give it a try? > But anyway, I hacked the following patch which seemed to > improve that behaviour. I haven't run any throughput numbers on it yet, > but I could if you're interested (and it's not completely broken!) Batching is certainly something that I have been considering, but apart from the excessive scanning bug, the per-ag inode tree lookups hve not featured prominently in any profiling I've done, so it hasn't been a high priority. You patch looks like it will work fine, but I think it can be made a lot cleaner. I'll have a closer look at this once I get to the bottom of the dbench hang you are seeing.... Cheers, Dave. -- Dave Chinner david@fromorbit.com xfs: add an AG iterator start rotor From: Dave Chinner <dchinner@redhat.com> To avoid multiple CPUs from executing inode cache shrinkers on the same AG all at the same time, make every shrinker call start on a different AG. This will mostly prevent concurrent shrinker calls from competing for the serialising pag_ici_lock and lock-stepping reclaim. Signed-off-by: Dave Chinner <dchinner@redhat.com> --- fs/xfs/linux-2.6/xfs_sync.c | 11 ++++++++++- fs/xfs/xfs_mount.h | 1 + 2 files changed, 11 insertions(+), 1 deletions(-) diff --git a/fs/xfs/linux-2.6/xfs_sync.c b/fs/xfs/linux-2.6/xfs_sync.c index dfcbd98..5322105 100644 --- a/fs/xfs/linux-2.6/xfs_sync.c +++ b/fs/xfs/linux-2.6/xfs_sync.c @@ -181,11 +181,14 @@ xfs_inode_ag_iterator( struct xfs_perag *pag; int error = 0; int last_error = 0; + xfs_agnumber_t start_ag; xfs_agnumber_t ag; int nr; + int looped = 0; nr = nr_to_scan ? *nr_to_scan : INT_MAX; - ag = 0; + start_ag = atomic_inc_return(&mp->m_agiter_rotor) & mp->m_sb.sb_agcount; + ag = start_ag; while ((pag = xfs_inode_ag_iter_next_pag(mp, &ag, tag))) { error = xfs_inode_ag_walk(mp, pag, execute, flags, tag, exclusive, &nr); @@ -197,6 +200,12 @@ xfs_inode_ag_iterator( } if (nr <= 0) break; + if (ag >= mp->m_sb.sb_agcount) { + looped = 1; + ag = 0; + } + if (ag >= start_ag && looped) + break; } if (nr_to_scan) *nr_to_scan = nr; diff --git a/fs/xfs/xfs_mount.h b/fs/xfs/xfs_mount.h index 622da21..fae61bb 100644 --- a/fs/xfs/xfs_mount.h +++ b/fs/xfs/xfs_mount.h @@ -199,6 +199,7 @@ typedef struct xfs_mount { __int64_t m_update_flags; /* sb flags we need to update on the next remount,rw */ struct shrinker m_inode_shrink; /* inode reclaim shrinker */ + atomic_t m_agiter_rotor; /* ag iterator start rotor */ } xfs_mount_t; /* _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply related [flat|nested] 76+ messages in thread
* Re: VFS scalability git tree 2010-07-28 12:57 ` Dave Chinner @ 2010-07-29 14:03 ` Nick Piggin -1 siblings, 0 replies; 76+ messages in thread From: Nick Piggin @ 2010-07-29 14:03 UTC (permalink / raw) To: Dave Chinner; +Cc: Nick Piggin, xfs, linux-fsdevel On Wed, Jul 28, 2010 at 10:57:17PM +1000, Dave Chinner wrote: > On Tue, Jul 27, 2010 at 06:06:32PM +1000, Nick Piggin wrote: > > On Tue, Jul 27, 2010 at 05:05:39PM +1000, Nick Piggin wrote: > > > On Fri, Jul 23, 2010 at 11:55:14PM +1000, Dave Chinner wrote: > > > > On Fri, Jul 23, 2010 at 05:01:00AM +1000, Nick Piggin wrote: > > > > > I'm pleased to announce I have a git tree up of my vfs scalability work. > > > > > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git > > > > > http://git.kernel.org/?p=linux/kernel/git/npiggin/linux-npiggin.git > > > > > > > > > > Branch vfs-scale-working > > > > > > > > With a production build (i.e. no lockdep, no xfs debug), I'll > > > > run the same fs_mark parallel create/unlink workload to show > > > > scalability as I ran here: > > > > > > > > http://oss.sgi.com/archives/xfs/2010-05/msg00329.html > > > > > > I've made a similar setup, 2s8c machine, but using 2GB ramdisk instead > > > of a real disk (I don't have easy access to a good disk setup ATM, but > > > I guess we're more interested in code above the block layer anyway). > > > > > > Made an XFS on /dev/ram0 with 16 ags, 64MB log, otherwise same config as > > > yours. > > > > > > I found that performance is a little unstable, so I sync and echo 3 > > > > drop_caches between each run. When it starts reclaiming memory, things > > > get a bit more erratic (and XFS seemed to be almost livelocking for tens > > > of seconds in inode reclaim). > > > > So about this XFS livelock type thingy. It looks like this, and happens > > periodically while running the above fs_mark benchmark requiring reclaim > > of inodes: > .... > > > Nothing much happening except 100% system time for seconds at a time > > (length of time varies). This is on a ramdisk, so it isn't waiting > > for IO. > > > > During this time, lots of things are contending on the lock: > > > > 60.37% fs_mark [kernel.kallsyms] [k] __write_lock_failed > > 4.30% kswapd0 [kernel.kallsyms] [k] __write_lock_failed > > 3.70% fs_mark [kernel.kallsyms] [k] try_wait_for_completion > > 3.59% fs_mark [kernel.kallsyms] [k] _raw_write_lock > > 3.46% kswapd1 [kernel.kallsyms] [k] __write_lock_failed > > | > > --- __write_lock_failed > > | > > |--99.92%-- xfs_inode_ag_walk > > | xfs_inode_ag_iterator > > | xfs_reclaim_inode_shrink > > | shrink_slab > > | shrink_zone > > | balance_pgdat > > | kswapd > > | kthread > > | kernel_thread_helper > > --0.08%-- [...] > > > > 3.02% fs_mark [kernel.kallsyms] [k] _raw_spin_lock > > 1.82% fs_mark [kernel.kallsyms] [k] _xfs_buf_find > > 1.16% fs_mark [kernel.kallsyms] [k] memcpy > > 0.86% fs_mark [kernel.kallsyms] [k] _raw_spin_lock_irqsave > > 0.75% fs_mark [kernel.kallsyms] [k] xfs_log_commit_cil > > | > > --- xfs_log_commit_cil > > _xfs_trans_commit > > | > > |--60.00%-- xfs_remove > > | xfs_vn_unlink > > | vfs_unlink > > | do_unlinkat > > | sys_unlink > > > > I'm not sure if there was a long-running read locker in there causing > > all the write lockers to fail, or if they are just running into one > > another. > > The longest hold is in the inode cluster writeback > (xfs_iflush_cluster), but if there is no IO then I don't see how > that would be a problem. No I wasn't suggesting there was, just that there could have been one that I didn't notice in profiles (ie. because it had taken read lock rather than spinning on it). > I suspect that it might be caused by having several CPUs > all trying to run the shrinker at the same time and them all > starting at the same AG and therefore lockstepping and getting > nothing done because they are all scanning the same inodes. I think that is the most likely answer, yes. > Maybe a start AG rotor for xfs_inode_ag_iterator() is needed to > avoid this lockstepping. I've attached a patch below to do this > - can you give it a try? Cool yes I will. I could try it in combination with the batching patch too. Thanks. > > But anyway, I hacked the following patch which seemed to > > improve that behaviour. I haven't run any throughput numbers on it yet, > > but I could if you're interested (and it's not completely broken!) > > Batching is certainly something that I have been considering, but > apart from the excessive scanning bug, the per-ag inode tree lookups > hve not featured prominently in any profiling I've done, so it > hasn't been a high priority. > > You patch looks like it will work fine, but I think it can be made a > lot cleaner. I'll have a closer look at this once I get to the bottom of > the dbench hang you are seeing.... Well I'll see if I can measure any efficiency or lock contention improvements with it and report back. Might have to wait till the weekend. ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: VFS scalability git tree @ 2010-07-29 14:03 ` Nick Piggin 0 siblings, 0 replies; 76+ messages in thread From: Nick Piggin @ 2010-07-29 14:03 UTC (permalink / raw) To: Dave Chinner; +Cc: linux-fsdevel, Nick Piggin, xfs On Wed, Jul 28, 2010 at 10:57:17PM +1000, Dave Chinner wrote: > On Tue, Jul 27, 2010 at 06:06:32PM +1000, Nick Piggin wrote: > > On Tue, Jul 27, 2010 at 05:05:39PM +1000, Nick Piggin wrote: > > > On Fri, Jul 23, 2010 at 11:55:14PM +1000, Dave Chinner wrote: > > > > On Fri, Jul 23, 2010 at 05:01:00AM +1000, Nick Piggin wrote: > > > > > I'm pleased to announce I have a git tree up of my vfs scalability work. > > > > > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git > > > > > http://git.kernel.org/?p=linux/kernel/git/npiggin/linux-npiggin.git > > > > > > > > > > Branch vfs-scale-working > > > > > > > > With a production build (i.e. no lockdep, no xfs debug), I'll > > > > run the same fs_mark parallel create/unlink workload to show > > > > scalability as I ran here: > > > > > > > > http://oss.sgi.com/archives/xfs/2010-05/msg00329.html > > > > > > I've made a similar setup, 2s8c machine, but using 2GB ramdisk instead > > > of a real disk (I don't have easy access to a good disk setup ATM, but > > > I guess we're more interested in code above the block layer anyway). > > > > > > Made an XFS on /dev/ram0 with 16 ags, 64MB log, otherwise same config as > > > yours. > > > > > > I found that performance is a little unstable, so I sync and echo 3 > > > > drop_caches between each run. When it starts reclaiming memory, things > > > get a bit more erratic (and XFS seemed to be almost livelocking for tens > > > of seconds in inode reclaim). > > > > So about this XFS livelock type thingy. It looks like this, and happens > > periodically while running the above fs_mark benchmark requiring reclaim > > of inodes: > .... > > > Nothing much happening except 100% system time for seconds at a time > > (length of time varies). This is on a ramdisk, so it isn't waiting > > for IO. > > > > During this time, lots of things are contending on the lock: > > > > 60.37% fs_mark [kernel.kallsyms] [k] __write_lock_failed > > 4.30% kswapd0 [kernel.kallsyms] [k] __write_lock_failed > > 3.70% fs_mark [kernel.kallsyms] [k] try_wait_for_completion > > 3.59% fs_mark [kernel.kallsyms] [k] _raw_write_lock > > 3.46% kswapd1 [kernel.kallsyms] [k] __write_lock_failed > > | > > --- __write_lock_failed > > | > > |--99.92%-- xfs_inode_ag_walk > > | xfs_inode_ag_iterator > > | xfs_reclaim_inode_shrink > > | shrink_slab > > | shrink_zone > > | balance_pgdat > > | kswapd > > | kthread > > | kernel_thread_helper > > --0.08%-- [...] > > > > 3.02% fs_mark [kernel.kallsyms] [k] _raw_spin_lock > > 1.82% fs_mark [kernel.kallsyms] [k] _xfs_buf_find > > 1.16% fs_mark [kernel.kallsyms] [k] memcpy > > 0.86% fs_mark [kernel.kallsyms] [k] _raw_spin_lock_irqsave > > 0.75% fs_mark [kernel.kallsyms] [k] xfs_log_commit_cil > > | > > --- xfs_log_commit_cil > > _xfs_trans_commit > > | > > |--60.00%-- xfs_remove > > | xfs_vn_unlink > > | vfs_unlink > > | do_unlinkat > > | sys_unlink > > > > I'm not sure if there was a long-running read locker in there causing > > all the write lockers to fail, or if they are just running into one > > another. > > The longest hold is in the inode cluster writeback > (xfs_iflush_cluster), but if there is no IO then I don't see how > that would be a problem. No I wasn't suggesting there was, just that there could have been one that I didn't notice in profiles (ie. because it had taken read lock rather than spinning on it). > I suspect that it might be caused by having several CPUs > all trying to run the shrinker at the same time and them all > starting at the same AG and therefore lockstepping and getting > nothing done because they are all scanning the same inodes. I think that is the most likely answer, yes. > Maybe a start AG rotor for xfs_inode_ag_iterator() is needed to > avoid this lockstepping. I've attached a patch below to do this > - can you give it a try? Cool yes I will. I could try it in combination with the batching patch too. Thanks. > > But anyway, I hacked the following patch which seemed to > > improve that behaviour. I haven't run any throughput numbers on it yet, > > but I could if you're interested (and it's not completely broken!) > > Batching is certainly something that I have been considering, but > apart from the excessive scanning bug, the per-ag inode tree lookups > hve not featured prominently in any profiling I've done, so it > hasn't been a high priority. > > You patch looks like it will work fine, but I think it can be made a > lot cleaner. I'll have a closer look at this once I get to the bottom of > the dbench hang you are seeing.... Well I'll see if I can measure any efficiency or lock contention improvements with it and report back. Might have to wait till the weekend. _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: VFS scalability git tree 2010-07-27 7:05 ` Nick Piggin @ 2010-07-27 11:09 ` Nick Piggin -1 siblings, 0 replies; 76+ messages in thread From: Nick Piggin @ 2010-07-27 11:09 UTC (permalink / raw) To: Nick Piggin Cc: Dave Chinner, linux-fsdevel, linux-kernel, linux-mm, Frank Mayhar, John Stultz On Tue, Jul 27, 2010 at 05:05:39PM +1000, Nick Piggin wrote: > On Fri, Jul 23, 2010 at 11:55:14PM +1000, Dave Chinner wrote: > > On Fri, Jul 23, 2010 at 05:01:00AM +1000, Nick Piggin wrote: > > > I'm pleased to announce I have a git tree up of my vfs scalability work. > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git > > > http://git.kernel.org/?p=linux/kernel/git/npiggin/linux-npiggin.git > > > > > > Branch vfs-scale-working > > > > With a production build (i.e. no lockdep, no xfs debug), I'll > > run the same fs_mark parallel create/unlink workload to show > > scalability as I ran here: > > > > http://oss.sgi.com/archives/xfs/2010-05/msg00329.html > > I've made a similar setup, 2s8c machine, but using 2GB ramdisk instead > of a real disk (I don't have easy access to a good disk setup ATM, but > I guess we're more interested in code above the block layer anyway). > > Made an XFS on /dev/ram0 with 16 ags, 64MB log, otherwise same config as > yours. I also tried dbench on this setup. 20 runs of dbench -t20 8 (that is a 20 second run, 8 clients). Numbers are throughput, higher is better: N Min Max Median Avg Stddev vanilla 20 2219.19 2249.43 2230.43 2230.9915 7.2528893 scale 20 2428.21 2490.8 2437.86 2444.111 16.668256 Difference at 95.0% confidence 213.119 +/- 8.22695 9.55268% +/- 0.368757% (Student's t, pooled s = 12.8537) vfs-scale is 9.5% or 210MB/s faster than vanilla. Like fs_mark, dbench has creat/unlink activity, so I hope rcu-inodes should not be such a problem in practice. In my creat/unlink benchmark, it is creating and destroying one inode repeatedly, which is the absolute worst case for rcu-inodes. Wheras in most real workloads would be creating and destroying many inodes, which is not such a dis advantage for rcu-inodes. Incidentally, XFS was by far the fastest "real" filesystem I tested on this workload. ext4 was around 1700MB/s (ext2 was around 3100MB/s and ramfs is 3350MB/s). ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: VFS scalability git tree @ 2010-07-27 11:09 ` Nick Piggin 0 siblings, 0 replies; 76+ messages in thread From: Nick Piggin @ 2010-07-27 11:09 UTC (permalink / raw) To: Nick Piggin Cc: Dave Chinner, linux-fsdevel, linux-kernel, linux-mm, Frank Mayhar, John Stultz On Tue, Jul 27, 2010 at 05:05:39PM +1000, Nick Piggin wrote: > On Fri, Jul 23, 2010 at 11:55:14PM +1000, Dave Chinner wrote: > > On Fri, Jul 23, 2010 at 05:01:00AM +1000, Nick Piggin wrote: > > > I'm pleased to announce I have a git tree up of my vfs scalability work. > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git > > > http://git.kernel.org/?p=linux/kernel/git/npiggin/linux-npiggin.git > > > > > > Branch vfs-scale-working > > > > With a production build (i.e. no lockdep, no xfs debug), I'll > > run the same fs_mark parallel create/unlink workload to show > > scalability as I ran here: > > > > http://oss.sgi.com/archives/xfs/2010-05/msg00329.html > > I've made a similar setup, 2s8c machine, but using 2GB ramdisk instead > of a real disk (I don't have easy access to a good disk setup ATM, but > I guess we're more interested in code above the block layer anyway). > > Made an XFS on /dev/ram0 with 16 ags, 64MB log, otherwise same config as > yours. I also tried dbench on this setup. 20 runs of dbench -t20 8 (that is a 20 second run, 8 clients). Numbers are throughput, higher is better: N Min Max Median Avg Stddev vanilla 20 2219.19 2249.43 2230.43 2230.9915 7.2528893 scale 20 2428.21 2490.8 2437.86 2444.111 16.668256 Difference at 95.0% confidence 213.119 +/- 8.22695 9.55268% +/- 0.368757% (Student's t, pooled s = 12.8537) vfs-scale is 9.5% or 210MB/s faster than vanilla. Like fs_mark, dbench has creat/unlink activity, so I hope rcu-inodes should not be such a problem in practice. In my creat/unlink benchmark, it is creating and destroying one inode repeatedly, which is the absolute worst case for rcu-inodes. Wheras in most real workloads would be creating and destroying many inodes, which is not such a dis advantage for rcu-inodes. Incidentally, XFS was by far the fastest "real" filesystem I tested on this workload. ext4 was around 1700MB/s (ext2 was around 3100MB/s and ramfs is 3350MB/s). -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: VFS scalability git tree 2010-07-27 7:05 ` Nick Piggin @ 2010-07-27 13:18 ` Dave Chinner -1 siblings, 0 replies; 76+ messages in thread From: Dave Chinner @ 2010-07-27 13:18 UTC (permalink / raw) To: Nick Piggin Cc: linux-fsdevel, linux-kernel, linux-mm, Frank Mayhar, John Stultz On Tue, Jul 27, 2010 at 05:05:39PM +1000, Nick Piggin wrote: > On Fri, Jul 23, 2010 at 11:55:14PM +1000, Dave Chinner wrote: > > On Fri, Jul 23, 2010 at 05:01:00AM +1000, Nick Piggin wrote: > > > I'm pleased to announce I have a git tree up of my vfs scalability work. > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git > > > http://git.kernel.org/?p=linux/kernel/git/npiggin/linux-npiggin.git > > > > > > Branch vfs-scale-working > > > > With a production build (i.e. no lockdep, no xfs debug), I'll > > run the same fs_mark parallel create/unlink workload to show > > scalability as I ran here: > > > > http://oss.sgi.com/archives/xfs/2010-05/msg00329.html > > I've made a similar setup, 2s8c machine, but using 2GB ramdisk instead > of a real disk (I don't have easy access to a good disk setup ATM, but > I guess we're more interested in code above the block layer anyway). > > Made an XFS on /dev/ram0 with 16 ags, 64MB log, otherwise same config as > yours. A s a personal prefernce, I don't like testing filesystem performance on ramdisks because it hides problems caused by changes in IO latency. I'll come back to this later. > I found that performance is a little unstable, so I sync and echo 3 > > drop_caches between each run. Quite possibly because of the smaller log - that will cause more frequent pushing on the log tail and hence I/O patterns will vary a bit... Also, keep in mind that delayed logging is shiny and new - it has increased XFS metadata performance and parallelism by an order of magnitude and so we're really seeing new a bunch of brand new issues that have never been seen before with this functionality. As such, there's still some interactions I haven't got to the bottom of with delayed logging - it's stable enough to use and benchmark and won't corrupt anything but there are still has some warts we need to solve. The difficulty (as always) is in reliably reproducing the bad behaviour. > When it starts reclaiming memory, things > get a bit more erratic (and XFS seemed to be almost livelocking for tens > of seconds in inode reclaim). I can't say that I've seen this - even when testing up to 10m inodes. Yes, kswapd is almost permanently active on these runs, but when creating 100,000 inodes/s we also need to be reclaiming 100,000 inodes/s so it's not surprising that when 7 CPUs are doing allocation we need at least one CPU to run reclaim.... > So I started with 50 runs of fs_mark > -n 20000 (which did not cause reclaim), rebuilding a new filesystem > between every run. > > That gave the following files/sec numbers: > N Min Max Median Avg Stddev > x 50 100986.4 127622 125013.4 123248.82 5244.1988 > + 50 100967.6 135918.6 130214.9 127926.94 6374.6975 > Difference at 95.0% confidence > 4678.12 +/- 2316.07 > 3.79567% +/- 1.87919% > (Student's t, pooled s = 5836.88) > > This is 3.8% in favour of vfs-scale-working. > > I then did 10 runs of -n 20000 but with -L 4 (4 iterations) which did > start to fill up memory and cause reclaim during the 2nd and subsequent > iterations. I haven't used this mode, so I can't really comment on the results you are seeing. > > enabled. ext4 is using default mkfs and mount parameters except for > > barrier=0. All numbers are averages of three runs. > > > > fs_mark rate (thousands of files/second) > > 2.6.35-rc5 2.6.35-rc5-scale > > threads xfs ext4 xfs ext4 > > 1 20 39 20 39 > > 2 35 55 35 57 > > 4 60 41 57 42 > > 8 79 9 75 9 > > > > ext4 is getting IO bound at more than 2 threads, so apart from > > pointing out that XFS is 8-9x faster than ext4 at 8 thread, I'm > > going to ignore ext4 for the purposes of testing scalability here. > > > > For XFS w/ delayed logging, 2.6.35-rc5 is only getting to about 600% > > CPU and with Nick's patches it's about 650% (10% higher) for > > slightly lower throughput. So at this class of machine for this > > workload, the changes result in a slight reduction in scalability. > > I wonder if these results are stable. It's possible that changes in > reclaim behaviour are causing my patches to require more IO for a > given unit of work? More likely that's the result of using a smaller log size because it will require more frequent metadata pushes to make space for new transactions. > I was seeing XFS 'livelock' in reclaim more with my patches, it > could be due to more parallelism now being allowed from the vfs and > reclaim. > > Based on my above numbers, I don't see that rcu-inodes is causing a > problem, and in terms of SMP scalability, there is really no way that > vanilla is more scalable, so I'm interested to see where this slowdown > is coming from. As I said initially, ram disks hide IO latency changes resulting from increased numbers of IO or increases in seek distances. My initial guess is the change in inode reclaim behaviour causing different IO patterns and more seeks under reclaim because the zone based reclaim is no longer reclaiming inodes in the order they are created (i.e. we are not doing sequential inode reclaim any more. FWIW, I use PCP monitoring graphs to correlate behavioural changes across different subsystems because it is far easier to relate information visually than it is by looking at raw numbers or traces. I think this graph shows the effect of relcaim on performance most clearly: http://userweb.kernel.org/~dgc/shrinker-2.6.36/fs_mark-2.6.35-rc3-context-only-per-xfs-batch6-16x500-xfs.png It's pretty clear that when the inode/dentry cache shrinkers are running, sustained create/unlink performance goes right down. From a different tab not in the screen shot (the other "test-4" tab), I could see CPU usage also goes down and the disk iops go way up whenever the create/unlink performance dropped. This same behaviour happens with the vfs-scale patchset, so it's not related to lock contention - just aggressive reclaim of still-dirty inodes. FYI, The patch under test there was the XFS shrinker ignoring 7 out of 8 shrinker calls and then on the 8th call doing the work of all previous calls. i.e emulating SHRINK_BATCH = 1024. Interestingly enough, that one change reduced the runtime of the 8m inode create/unlink load by ~25% (from ~24min to ~18min). That is by far the largest improvement I've been able to obtain from modifying the shrinker code, and it is from those sorts of observations that I think that IO being issued from reclaim is currently the most significant performance limiting factor for XFS in this sort of workload.... Cheers, Dave. -- Dave Chinner david@fromorbit.com ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: VFS scalability git tree @ 2010-07-27 13:18 ` Dave Chinner 0 siblings, 0 replies; 76+ messages in thread From: Dave Chinner @ 2010-07-27 13:18 UTC (permalink / raw) To: Nick Piggin Cc: linux-fsdevel, linux-kernel, linux-mm, Frank Mayhar, John Stultz On Tue, Jul 27, 2010 at 05:05:39PM +1000, Nick Piggin wrote: > On Fri, Jul 23, 2010 at 11:55:14PM +1000, Dave Chinner wrote: > > On Fri, Jul 23, 2010 at 05:01:00AM +1000, Nick Piggin wrote: > > > I'm pleased to announce I have a git tree up of my vfs scalability work. > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git > > > http://git.kernel.org/?p=linux/kernel/git/npiggin/linux-npiggin.git > > > > > > Branch vfs-scale-working > > > > With a production build (i.e. no lockdep, no xfs debug), I'll > > run the same fs_mark parallel create/unlink workload to show > > scalability as I ran here: > > > > http://oss.sgi.com/archives/xfs/2010-05/msg00329.html > > I've made a similar setup, 2s8c machine, but using 2GB ramdisk instead > of a real disk (I don't have easy access to a good disk setup ATM, but > I guess we're more interested in code above the block layer anyway). > > Made an XFS on /dev/ram0 with 16 ags, 64MB log, otherwise same config as > yours. A s a personal prefernce, I don't like testing filesystem performance on ramdisks because it hides problems caused by changes in IO latency. I'll come back to this later. > I found that performance is a little unstable, so I sync and echo 3 > > drop_caches between each run. Quite possibly because of the smaller log - that will cause more frequent pushing on the log tail and hence I/O patterns will vary a bit... Also, keep in mind that delayed logging is shiny and new - it has increased XFS metadata performance and parallelism by an order of magnitude and so we're really seeing new a bunch of brand new issues that have never been seen before with this functionality. As such, there's still some interactions I haven't got to the bottom of with delayed logging - it's stable enough to use and benchmark and won't corrupt anything but there are still has some warts we need to solve. The difficulty (as always) is in reliably reproducing the bad behaviour. > When it starts reclaiming memory, things > get a bit more erratic (and XFS seemed to be almost livelocking for tens > of seconds in inode reclaim). I can't say that I've seen this - even when testing up to 10m inodes. Yes, kswapd is almost permanently active on these runs, but when creating 100,000 inodes/s we also need to be reclaiming 100,000 inodes/s so it's not surprising that when 7 CPUs are doing allocation we need at least one CPU to run reclaim.... > So I started with 50 runs of fs_mark > -n 20000 (which did not cause reclaim), rebuilding a new filesystem > between every run. > > That gave the following files/sec numbers: > N Min Max Median Avg Stddev > x 50 100986.4 127622 125013.4 123248.82 5244.1988 > + 50 100967.6 135918.6 130214.9 127926.94 6374.6975 > Difference at 95.0% confidence > 4678.12 +/- 2316.07 > 3.79567% +/- 1.87919% > (Student's t, pooled s = 5836.88) > > This is 3.8% in favour of vfs-scale-working. > > I then did 10 runs of -n 20000 but with -L 4 (4 iterations) which did > start to fill up memory and cause reclaim during the 2nd and subsequent > iterations. I haven't used this mode, so I can't really comment on the results you are seeing. > > enabled. ext4 is using default mkfs and mount parameters except for > > barrier=0. All numbers are averages of three runs. > > > > fs_mark rate (thousands of files/second) > > 2.6.35-rc5 2.6.35-rc5-scale > > threads xfs ext4 xfs ext4 > > 1 20 39 20 39 > > 2 35 55 35 57 > > 4 60 41 57 42 > > 8 79 9 75 9 > > > > ext4 is getting IO bound at more than 2 threads, so apart from > > pointing out that XFS is 8-9x faster than ext4 at 8 thread, I'm > > going to ignore ext4 for the purposes of testing scalability here. > > > > For XFS w/ delayed logging, 2.6.35-rc5 is only getting to about 600% > > CPU and with Nick's patches it's about 650% (10% higher) for > > slightly lower throughput. So at this class of machine for this > > workload, the changes result in a slight reduction in scalability. > > I wonder if these results are stable. It's possible that changes in > reclaim behaviour are causing my patches to require more IO for a > given unit of work? More likely that's the result of using a smaller log size because it will require more frequent metadata pushes to make space for new transactions. > I was seeing XFS 'livelock' in reclaim more with my patches, it > could be due to more parallelism now being allowed from the vfs and > reclaim. > > Based on my above numbers, I don't see that rcu-inodes is causing a > problem, and in terms of SMP scalability, there is really no way that > vanilla is more scalable, so I'm interested to see where this slowdown > is coming from. As I said initially, ram disks hide IO latency changes resulting from increased numbers of IO or increases in seek distances. My initial guess is the change in inode reclaim behaviour causing different IO patterns and more seeks under reclaim because the zone based reclaim is no longer reclaiming inodes in the order they are created (i.e. we are not doing sequential inode reclaim any more. FWIW, I use PCP monitoring graphs to correlate behavioural changes across different subsystems because it is far easier to relate information visually than it is by looking at raw numbers or traces. I think this graph shows the effect of relcaim on performance most clearly: http://userweb.kernel.org/~dgc/shrinker-2.6.36/fs_mark-2.6.35-rc3-context-only-per-xfs-batch6-16x500-xfs.png It's pretty clear that when the inode/dentry cache shrinkers are running, sustained create/unlink performance goes right down. From a different tab not in the screen shot (the other "test-4" tab), I could see CPU usage also goes down and the disk iops go way up whenever the create/unlink performance dropped. This same behaviour happens with the vfs-scale patchset, so it's not related to lock contention - just aggressive reclaim of still-dirty inodes. FYI, The patch under test there was the XFS shrinker ignoring 7 out of 8 shrinker calls and then on the 8th call doing the work of all previous calls. i.e emulating SHRINK_BATCH = 1024. Interestingly enough, that one change reduced the runtime of the 8m inode create/unlink load by ~25% (from ~24min to ~18min). That is by far the largest improvement I've been able to obtain from modifying the shrinker code, and it is from those sorts of observations that I think that IO being issued from reclaim is currently the most significant performance limiting factor for XFS in this sort of workload.... Cheers, Dave. -- Dave Chinner david@fromorbit.com -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: VFS scalability git tree 2010-07-27 13:18 ` Dave Chinner @ 2010-07-27 15:09 ` Nick Piggin -1 siblings, 0 replies; 76+ messages in thread From: Nick Piggin @ 2010-07-27 15:09 UTC (permalink / raw) To: Dave Chinner Cc: Nick Piggin, linux-fsdevel, linux-kernel, linux-mm, Frank Mayhar, John Stultz On Tue, Jul 27, 2010 at 11:18:10PM +1000, Dave Chinner wrote: > On Tue, Jul 27, 2010 at 05:05:39PM +1000, Nick Piggin wrote: > > On Fri, Jul 23, 2010 at 11:55:14PM +1000, Dave Chinner wrote: > > > On Fri, Jul 23, 2010 at 05:01:00AM +1000, Nick Piggin wrote: > > > > I'm pleased to announce I have a git tree up of my vfs scalability work. > > > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git > > > > http://git.kernel.org/?p=linux/kernel/git/npiggin/linux-npiggin.git > > > > > > > > Branch vfs-scale-working > > > > > > With a production build (i.e. no lockdep, no xfs debug), I'll > > > run the same fs_mark parallel create/unlink workload to show > > > scalability as I ran here: > > > > > > http://oss.sgi.com/archives/xfs/2010-05/msg00329.html > > > > I've made a similar setup, 2s8c machine, but using 2GB ramdisk instead > > of a real disk (I don't have easy access to a good disk setup ATM, but > > I guess we're more interested in code above the block layer anyway). > > > > Made an XFS on /dev/ram0 with 16 ags, 64MB log, otherwise same config as > > yours. > > A s a personal prefernce, I don't like testing filesystem performance > on ramdisks because it hides problems caused by changes in IO > latency. I'll come back to this later. Very true, although it's good if you don't have some fast disks, and it can be good to trigger different races than disks tend to. So I still want to get to the bottom of the slowdown you saw on vfs-scale. > > I found that performance is a little unstable, so I sync and echo 3 > > > drop_caches between each run. > > Quite possibly because of the smaller log - that will cause more > frequent pushing on the log tail and hence I/O patterns will vary a > bit... Well... I think the test case (or how I'm running it) is simply a bit unstable. I mean, there are subtle interactions all the way from the CPU scheduler to the disk, so when I say unstable I'm not particularly blaming XFS :) > Also, keep in mind that delayed logging is shiny and new - it has > increased XFS metadata performance and parallelism by an order of > magnitude and so we're really seeing new a bunch of brand new issues > that have never been seen before with this functionality. As such, > there's still some interactions I haven't got to the bottom of with > delayed logging - it's stable enough to use and benchmark and won't > corrupt anything but there are still has some warts we need to > solve. The difficulty (as always) is in reliably reproducing the bad > behaviour. Sure, and I didn't see any corruptions, it seems pretty stable and scalability is better than other filesystems. I'll see if I can give a better recipe to reproduce the 'livelock'ish behaviour. > > I then did 10 runs of -n 20000 but with -L 4 (4 iterations) which did > > start to fill up memory and cause reclaim during the 2nd and subsequent > > iterations. > > I haven't used this mode, so I can't really comment on the results > you are seeing. It's a bit strange. Help says it should clear inodes between iterations (without the -k flag), but it does not seem to. > > > enabled. ext4 is using default mkfs and mount parameters except for > > > barrier=0. All numbers are averages of three runs. > > > > > > fs_mark rate (thousands of files/second) > > > 2.6.35-rc5 2.6.35-rc5-scale > > > threads xfs ext4 xfs ext4 > > > 1 20 39 20 39 > > > 2 35 55 35 57 > > > 4 60 41 57 42 > > > 8 79 9 75 9 > > > > > > ext4 is getting IO bound at more than 2 threads, so apart from > > > pointing out that XFS is 8-9x faster than ext4 at 8 thread, I'm > > > going to ignore ext4 for the purposes of testing scalability here. > > > > > > For XFS w/ delayed logging, 2.6.35-rc5 is only getting to about 600% > > > CPU and with Nick's patches it's about 650% (10% higher) for > > > slightly lower throughput. So at this class of machine for this > > > workload, the changes result in a slight reduction in scalability. > > > > I wonder if these results are stable. It's possible that changes in > > reclaim behaviour are causing my patches to require more IO for a > > given unit of work? > > More likely that's the result of using a smaller log size because it > will require more frequent metadata pushes to make space for new > transactions. I was just checking whether your numbers are stable (where you saw some slowdown with vfs-scale patches), and what could be the cause. I agree that running real disks could make big changes in behaviour. > > I was seeing XFS 'livelock' in reclaim more with my patches, it > > could be due to more parallelism now being allowed from the vfs and > > reclaim. > > > > Based on my above numbers, I don't see that rcu-inodes is causing a > > problem, and in terms of SMP scalability, there is really no way that > > vanilla is more scalable, so I'm interested to see where this slowdown > > is coming from. > > As I said initially, ram disks hide IO latency changes resulting > from increased numbers of IO or increases in seek distances. My > initial guess is the change in inode reclaim behaviour causing > different IO patterns and more seeks under reclaim because the zone > based reclaim is no longer reclaiming inodes in the order > they are created (i.e. we are not doing sequential inode reclaim any > more. Sounds plausible. I'll do more investigations along those lines. > FWIW, I use PCP monitoring graphs to correlate behavioural changes > across different subsystems because it is far easier to relate > information visually than it is by looking at raw numbers or traces. > I think this graph shows the effect of relcaim on performance > most clearly: > > http://userweb.kernel.org/~dgc/shrinker-2.6.36/fs_mark-2.6.35-rc3-context-only-per-xfs-batch6-16x500-xfs.png I haven't actually used that, it looks interesting. > It's pretty clear that when the inode/dentry cache shrinkers are > running, sustained create/unlink performance goes right down. From a > different tab not in the screen shot (the other "test-4" tab), I > could see CPU usage also goes down and the disk iops go way up > whenever the create/unlink performance dropped. This same behaviour > happens with the vfs-scale patchset, so it's not related to lock > contention - just aggressive reclaim of still-dirty inodes. > > FYI, The patch under test there was the XFS shrinker ignoring 7 out > of 8 shrinker calls and then on the 8th call doing the work of all > previous calls. i.e emulating SHRINK_BATCH = 1024. Interestingly > enough, that one change reduced the runtime of the 8m inode > create/unlink load by ~25% (from ~24min to ~18min). Hmm, interesting. Well that's naturally configurable with the shrinker API changes I'm hoping to have merged. I'll plan to push that ahead of the vfs-scale patches of course. > That is by far the largest improvement I've been able to obtain from > modifying the shrinker code, and it is from those sorts of > observations that I think that IO being issued from reclaim is > currently the most significant performance limiting factor for XFS > in this sort of workload.... How is the xfs inode reclaim tied to linux inode reclaim? Does the xfs inode not become reclaimable until some time after the linux inode is reclaimed? Or what? Do all or most of the xfs inodes require IO before being reclaimed during this test? I wonder if you could throttle them a bit or sort them somehow so that they tend to be cleaned by writeout and reclaim just comes after and removes the clean ones, like pagecache reclaim is (supposed) to work.? ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: VFS scalability git tree @ 2010-07-27 15:09 ` Nick Piggin 0 siblings, 0 replies; 76+ messages in thread From: Nick Piggin @ 2010-07-27 15:09 UTC (permalink / raw) To: Dave Chinner Cc: Nick Piggin, linux-fsdevel, linux-kernel, linux-mm, Frank Mayhar, John Stultz On Tue, Jul 27, 2010 at 11:18:10PM +1000, Dave Chinner wrote: > On Tue, Jul 27, 2010 at 05:05:39PM +1000, Nick Piggin wrote: > > On Fri, Jul 23, 2010 at 11:55:14PM +1000, Dave Chinner wrote: > > > On Fri, Jul 23, 2010 at 05:01:00AM +1000, Nick Piggin wrote: > > > > I'm pleased to announce I have a git tree up of my vfs scalability work. > > > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git > > > > http://git.kernel.org/?p=linux/kernel/git/npiggin/linux-npiggin.git > > > > > > > > Branch vfs-scale-working > > > > > > With a production build (i.e. no lockdep, no xfs debug), I'll > > > run the same fs_mark parallel create/unlink workload to show > > > scalability as I ran here: > > > > > > http://oss.sgi.com/archives/xfs/2010-05/msg00329.html > > > > I've made a similar setup, 2s8c machine, but using 2GB ramdisk instead > > of a real disk (I don't have easy access to a good disk setup ATM, but > > I guess we're more interested in code above the block layer anyway). > > > > Made an XFS on /dev/ram0 with 16 ags, 64MB log, otherwise same config as > > yours. > > A s a personal prefernce, I don't like testing filesystem performance > on ramdisks because it hides problems caused by changes in IO > latency. I'll come back to this later. Very true, although it's good if you don't have some fast disks, and it can be good to trigger different races than disks tend to. So I still want to get to the bottom of the slowdown you saw on vfs-scale. > > I found that performance is a little unstable, so I sync and echo 3 > > > drop_caches between each run. > > Quite possibly because of the smaller log - that will cause more > frequent pushing on the log tail and hence I/O patterns will vary a > bit... Well... I think the test case (or how I'm running it) is simply a bit unstable. I mean, there are subtle interactions all the way from the CPU scheduler to the disk, so when I say unstable I'm not particularly blaming XFS :) > Also, keep in mind that delayed logging is shiny and new - it has > increased XFS metadata performance and parallelism by an order of > magnitude and so we're really seeing new a bunch of brand new issues > that have never been seen before with this functionality. As such, > there's still some interactions I haven't got to the bottom of with > delayed logging - it's stable enough to use and benchmark and won't > corrupt anything but there are still has some warts we need to > solve. The difficulty (as always) is in reliably reproducing the bad > behaviour. Sure, and I didn't see any corruptions, it seems pretty stable and scalability is better than other filesystems. I'll see if I can give a better recipe to reproduce the 'livelock'ish behaviour. > > I then did 10 runs of -n 20000 but with -L 4 (4 iterations) which did > > start to fill up memory and cause reclaim during the 2nd and subsequent > > iterations. > > I haven't used this mode, so I can't really comment on the results > you are seeing. It's a bit strange. Help says it should clear inodes between iterations (without the -k flag), but it does not seem to. > > > enabled. ext4 is using default mkfs and mount parameters except for > > > barrier=0. All numbers are averages of three runs. > > > > > > fs_mark rate (thousands of files/second) > > > 2.6.35-rc5 2.6.35-rc5-scale > > > threads xfs ext4 xfs ext4 > > > 1 20 39 20 39 > > > 2 35 55 35 57 > > > 4 60 41 57 42 > > > 8 79 9 75 9 > > > > > > ext4 is getting IO bound at more than 2 threads, so apart from > > > pointing out that XFS is 8-9x faster than ext4 at 8 thread, I'm > > > going to ignore ext4 for the purposes of testing scalability here. > > > > > > For XFS w/ delayed logging, 2.6.35-rc5 is only getting to about 600% > > > CPU and with Nick's patches it's about 650% (10% higher) for > > > slightly lower throughput. So at this class of machine for this > > > workload, the changes result in a slight reduction in scalability. > > > > I wonder if these results are stable. It's possible that changes in > > reclaim behaviour are causing my patches to require more IO for a > > given unit of work? > > More likely that's the result of using a smaller log size because it > will require more frequent metadata pushes to make space for new > transactions. I was just checking whether your numbers are stable (where you saw some slowdown with vfs-scale patches), and what could be the cause. I agree that running real disks could make big changes in behaviour. > > I was seeing XFS 'livelock' in reclaim more with my patches, it > > could be due to more parallelism now being allowed from the vfs and > > reclaim. > > > > Based on my above numbers, I don't see that rcu-inodes is causing a > > problem, and in terms of SMP scalability, there is really no way that > > vanilla is more scalable, so I'm interested to see where this slowdown > > is coming from. > > As I said initially, ram disks hide IO latency changes resulting > from increased numbers of IO or increases in seek distances. My > initial guess is the change in inode reclaim behaviour causing > different IO patterns and more seeks under reclaim because the zone > based reclaim is no longer reclaiming inodes in the order > they are created (i.e. we are not doing sequential inode reclaim any > more. Sounds plausible. I'll do more investigations along those lines. > FWIW, I use PCP monitoring graphs to correlate behavioural changes > across different subsystems because it is far easier to relate > information visually than it is by looking at raw numbers or traces. > I think this graph shows the effect of relcaim on performance > most clearly: > > http://userweb.kernel.org/~dgc/shrinker-2.6.36/fs_mark-2.6.35-rc3-context-only-per-xfs-batch6-16x500-xfs.png I haven't actually used that, it looks interesting. > It's pretty clear that when the inode/dentry cache shrinkers are > running, sustained create/unlink performance goes right down. From a > different tab not in the screen shot (the other "test-4" tab), I > could see CPU usage also goes down and the disk iops go way up > whenever the create/unlink performance dropped. This same behaviour > happens with the vfs-scale patchset, so it's not related to lock > contention - just aggressive reclaim of still-dirty inodes. > > FYI, The patch under test there was the XFS shrinker ignoring 7 out > of 8 shrinker calls and then on the 8th call doing the work of all > previous calls. i.e emulating SHRINK_BATCH = 1024. Interestingly > enough, that one change reduced the runtime of the 8m inode > create/unlink load by ~25% (from ~24min to ~18min). Hmm, interesting. Well that's naturally configurable with the shrinker API changes I'm hoping to have merged. I'll plan to push that ahead of the vfs-scale patches of course. > That is by far the largest improvement I've been able to obtain from > modifying the shrinker code, and it is from those sorts of > observations that I think that IO being issued from reclaim is > currently the most significant performance limiting factor for XFS > in this sort of workload.... How is the xfs inode reclaim tied to linux inode reclaim? Does the xfs inode not become reclaimable until some time after the linux inode is reclaimed? Or what? Do all or most of the xfs inodes require IO before being reclaimed during this test? I wonder if you could throttle them a bit or sort them somehow so that they tend to be cleaned by writeout and reclaim just comes after and removes the clean ones, like pagecache reclaim is (supposed) to work.? -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: VFS scalability git tree 2010-07-27 15:09 ` Nick Piggin (?) @ 2010-07-28 4:59 ` Dave Chinner -1 siblings, 0 replies; 76+ messages in thread From: Dave Chinner @ 2010-07-28 4:59 UTC (permalink / raw) To: Nick Piggin Cc: Nick Piggin, linux-fsdevel, linux-kernel, linux-mm, Frank Mayhar, John Stultz On Wed, Jul 28, 2010 at 01:09:08AM +1000, Nick Piggin wrote: > On Tue, Jul 27, 2010 at 11:18:10PM +1000, Dave Chinner wrote: > > On Tue, Jul 27, 2010 at 05:05:39PM +1000, Nick Piggin wrote: > > > On Fri, Jul 23, 2010 at 11:55:14PM +1000, Dave Chinner wrote: > > solve. The difficulty (as always) is in reliably reproducing the bad > > behaviour. > > Sure, and I didn't see any corruptions, it seems pretty stable and > scalability is better than other filesystems. I'll see if I can > give a better recipe to reproduce the 'livelock'ish behaviour. Well, stable is a good start :) > > > > fs_mark rate (thousands of files/second) > > > > 2.6.35-rc5 2.6.35-rc5-scale > > > > threads xfs ext4 xfs ext4 > > > > 1 20 39 20 39 > > > > 2 35 55 35 57 > > > > 4 60 41 57 42 > > > > 8 79 9 75 9 > > > > > > > > ext4 is getting IO bound at more than 2 threads, so apart from > > > > pointing out that XFS is 8-9x faster than ext4 at 8 thread, I'm > > > > going to ignore ext4 for the purposes of testing scalability here. > > > > > > > > For XFS w/ delayed logging, 2.6.35-rc5 is only getting to about 600% > > > > CPU and with Nick's patches it's about 650% (10% higher) for > > > > slightly lower throughput. So at this class of machine for this > > > > workload, the changes result in a slight reduction in scalability. > > > > > > I wonder if these results are stable. It's possible that changes in > > > reclaim behaviour are causing my patches to require more IO for a > > > given unit of work? > > > > More likely that's the result of using a smaller log size because it > > will require more frequent metadata pushes to make space for new > > transactions. > > I was just checking whether your numbers are stable (where you > saw some slowdown with vfs-scale patches), and what could be the > cause. I agree that running real disks could make big changes in > behaviour. Yeah, the numbers are repeatable within about +/-5%. I generally don't bother with optimisations that result in gains/losses less than that because IO benchmarks that reliably repoduce results with more precise repeatability than that are few and far between. > > FWIW, I use PCP monitoring graphs to correlate behavioural changes > > across different subsystems because it is far easier to relate > > information visually than it is by looking at raw numbers or traces. > > I think this graph shows the effect of relcaim on performance > > most clearly: > > > > http://userweb.kernel.org/~dgc/shrinker-2.6.36/fs_mark-2.6.35-rc3-context-only-per-xfs-batch6-16x500-xfs.png > > I haven't actually used that, it looks interesting. The archiving side of PCP is the most useful, I find. i.e. being able to record the metrics into a file and analyse them with pmchart or other tools after the fact... > > That is by far the largest improvement I've been able to obtain from > > modifying the shrinker code, and it is from those sorts of > > observations that I think that IO being issued from reclaim is > > currently the most significant performance limiting factor for XFS > > in this sort of workload.... > > How is the xfs inode reclaim tied to linux inode reclaim? Does the > xfs inode not become reclaimable until some time after the linux inode > is reclaimed? Or what? The struct xfs_inode embeds a struct inode like so: struct xfs_inode { ..... struct inode i_inode; } so they are the same chunk of memory. XFS does not use the VFS inode hashes for finding inodes - that's what the per-ag radix trees are used for. The xfs_inode lives longer than the struct inode because we do non-trivial work after the VFS "reclaims" the struct inode. For example, when an inode is unlinked do not truncate or free the inode until after the VFS has finished with it - the inode remains on the unlinked list (orphaned in ext3 terms) from the time is is unlinked by the VFS to the time the last VFs reference goes away. When XFS gets it, XFS then issues the inactive transaction that takes the inode off the unlinked list and marks it free in the inode alloc btree. This transaction is asynchronous and dirties the xfs inode. Finally XFS will mark the inode as reclaimable via a radix tree tag. The final processing of the inode is then done via eaither a background relcaim walk from xfssyncd (every 30s) where it will do non-blocking operations to finalіze reclaim. It may take several passes to actually reclaim the inode. e.g. one pass to force the log if the inode is pinned, another pass to flush the inode to disk if it is dirty and not stale, and then another pass to reclaim the inode once clean. There may be multiple passes inbetween where the inode is skipped because those operations have not completed. And to top it all off, if the inode is looked up again (cache hit) while in the reclaimable state, it will be removed from the reclaim state and reused immediately. in this case we don't need to continue the reclaim processing other things will ensure all the correct information will go to disk. > Do all or most of the xfs inodes require IO before being reclaimed > during this test? Yes, because all the inode are being dirtied and they are being reclaimed faster than background flushing expires them. > I wonder if you could throttle them a bit or sort > them somehow so that they tend to be cleaned by writeout and reclaim > just comes after and removes the clean ones, like pagecache reclaim > is (supposed) to work.? The whole point of using the radix trees is to get nicely sorted reclaim IO - inodes are indexed by number, and the radix tree walk gives us ascending inode number (and hence ascending block number) reclaim - and the background reclaim allows optimal flushing to occur by aggregating all the IO into delayed write metadata buffers so they can be sorted and flushed to the elevator by the xfsbufd in the most optimal manner possible. The shrinker does preempt this somewhat, which is why delaying the XFS shrinker's work appears to improve things alot. If the shrinker is not running, the the background reclaim does exactly what you are suggesting. However, I don't think the increase in iops is caused by the XFS inode shrinker - I think that it is the VFS cache shrinkers. If you look at the the graphs in the link above, preformance doesn't decrease when the XFS inode cache is being shrunk (top chart, yellow trace) - it drops when the vfs caches are being shrunk (middle chart). I haven't correlated the behaviour any further than that because I haven't had time. FWIW, all this background reclaim, radix tree reclaim tagging and walking, embedded struct inodes, etc is all relatively new code. The oldest bit of it was introduced in 2.6.31 (I think) and so a significant part of what we are exploring here is uncharted territory. The changes to relcaim, etc are aprtially reponsible for the scalabilty we are geting from delayed logging, but there is certainly room for improvement.... Cheers, Dave. -- Dave Chinner david@fromorbit.com ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: VFS scalability git tree @ 2010-07-28 4:59 ` Dave Chinner 0 siblings, 0 replies; 76+ messages in thread From: Dave Chinner @ 2010-07-28 4:59 UTC (permalink / raw) To: Nick Piggin Cc: Nick Piggin, linux-fsdevel, linux-kernel, linux-mm, Frank Mayhar, John Stultz On Wed, Jul 28, 2010 at 01:09:08AM +1000, Nick Piggin wrote: > On Tue, Jul 27, 2010 at 11:18:10PM +1000, Dave Chinner wrote: > > On Tue, Jul 27, 2010 at 05:05:39PM +1000, Nick Piggin wrote: > > > On Fri, Jul 23, 2010 at 11:55:14PM +1000, Dave Chinner wrote: > > solve. The difficulty (as always) is in reliably reproducing the bad > > behaviour. > > Sure, and I didn't see any corruptions, it seems pretty stable and > scalability is better than other filesystems. I'll see if I can > give a better recipe to reproduce the 'livelock'ish behaviour. Well, stable is a good start :) > > > > fs_mark rate (thousands of files/second) > > > > 2.6.35-rc5 2.6.35-rc5-scale > > > > threads xfs ext4 xfs ext4 > > > > 1 20 39 20 39 > > > > 2 35 55 35 57 > > > > 4 60 41 57 42 > > > > 8 79 9 75 9 > > > > > > > > ext4 is getting IO bound at more than 2 threads, so apart from > > > > pointing out that XFS is 8-9x faster than ext4 at 8 thread, I'm > > > > going to ignore ext4 for the purposes of testing scalability here. > > > > > > > > For XFS w/ delayed logging, 2.6.35-rc5 is only getting to about 600% > > > > CPU and with Nick's patches it's about 650% (10% higher) for > > > > slightly lower throughput. So at this class of machine for this > > > > workload, the changes result in a slight reduction in scalability. > > > > > > I wonder if these results are stable. It's possible that changes in > > > reclaim behaviour are causing my patches to require more IO for a > > > given unit of work? > > > > More likely that's the result of using a smaller log size because it > > will require more frequent metadata pushes to make space for new > > transactions. > > I was just checking whether your numbers are stable (where you > saw some slowdown with vfs-scale patches), and what could be the > cause. I agree that running real disks could make big changes in > behaviour. Yeah, the numbers are repeatable within about +/-5%. I generally don't bother with optimisations that result in gains/losses less than that because IO benchmarks that reliably repoduce results with more precise repeatability than that are few and far between. > > FWIW, I use PCP monitoring graphs to correlate behavioural changes > > across different subsystems because it is far easier to relate > > information visually than it is by looking at raw numbers or traces. > > I think this graph shows the effect of relcaim on performance > > most clearly: > > > > http://userweb.kernel.org/~dgc/shrinker-2.6.36/fs_mark-2.6.35-rc3-context-only-per-xfs-batch6-16x500-xfs.png > > I haven't actually used that, it looks interesting. The archiving side of PCP is the most useful, I find. i.e. being able to record the metrics into a file and analyse them with pmchart or other tools after the fact... > > That is by far the largest improvement I've been able to obtain from > > modifying the shrinker code, and it is from those sorts of > > observations that I think that IO being issued from reclaim is > > currently the most significant performance limiting factor for XFS > > in this sort of workload.... > > How is the xfs inode reclaim tied to linux inode reclaim? Does the > xfs inode not become reclaimable until some time after the linux inode > is reclaimed? Or what? The struct xfs_inode embeds a struct inode like so: struct xfs_inode { ..... struct inode i_inode; } so they are the same chunk of memory. XFS does not use the VFS inode hashes for finding inodes - that's what the per-ag radix trees are used for. The xfs_inode lives longer than the struct inode because we do non-trivial work after the VFS "reclaims" the struct inode. For example, when an inode is unlinked do not truncate or free the inode until after the VFS has finished with it - the inode remains on the unlinked list (orphaned in ext3 terms) from the time is is unlinked by the VFS to the time the last VFs reference goes away. When XFS gets it, XFS then issues the inactive transaction that takes the inode off the unlinked list and marks it free in the inode alloc btree. This transaction is asynchronous and dirties the xfs inode. Finally XFS will mark the inode as reclaimable via a radix tree tag. The final processing of the inode is then done via eaither a background relcaim walk from xfssyncd (every 30s) where it will do non-blocking operations to finalN?ze reclaim. It may take several passes to actually reclaim the inode. e.g. one pass to force the log if the inode is pinned, another pass to flush the inode to disk if it is dirty and not stale, and then another pass to reclaim the inode once clean. There may be multiple passes inbetween where the inode is skipped because those operations have not completed. And to top it all off, if the inode is looked up again (cache hit) while in the reclaimable state, it will be removed from the reclaim state and reused immediately. in this case we don't need to continue the reclaim processing other things will ensure all the correct information will go to disk. > Do all or most of the xfs inodes require IO before being reclaimed > during this test? Yes, because all the inode are being dirtied and they are being reclaimed faster than background flushing expires them. > I wonder if you could throttle them a bit or sort > them somehow so that they tend to be cleaned by writeout and reclaim > just comes after and removes the clean ones, like pagecache reclaim > is (supposed) to work.? The whole point of using the radix trees is to get nicely sorted reclaim IO - inodes are indexed by number, and the radix tree walk gives us ascending inode number (and hence ascending block number) reclaim - and the background reclaim allows optimal flushing to occur by aggregating all the IO into delayed write metadata buffers so they can be sorted and flushed to the elevator by the xfsbufd in the most optimal manner possible. The shrinker does preempt this somewhat, which is why delaying the XFS shrinker's work appears to improve things alot. If the shrinker is not running, the the background reclaim does exactly what you are suggesting. However, I don't think the increase in iops is caused by the XFS inode shrinker - I think that it is the VFS cache shrinkers. If you look at the the graphs in the link above, preformance doesn't decrease when the XFS inode cache is being shrunk (top chart, yellow trace) - it drops when the vfs caches are being shrunk (middle chart). I haven't correlated the behaviour any further than that because I haven't had time. FWIW, all this background reclaim, radix tree reclaim tagging and walking, embedded struct inodes, etc is all relatively new code. The oldest bit of it was introduced in 2.6.31 (I think) and so a significant part of what we are exploring here is uncharted territory. The changes to relcaim, etc are aprtially reponsible for the scalabilty we are geting from delayed logging, but there is certainly room for improvement.... Cheers, Dave. -- Dave Chinner david@fromorbit.com -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: VFS scalability git tree @ 2010-07-28 4:59 ` Dave Chinner 0 siblings, 0 replies; 76+ messages in thread From: Dave Chinner @ 2010-07-28 4:59 UTC (permalink / raw) To: Nick Piggin Cc: Nick Piggin, linux-fsdevel, linux-kernel, linux-mm, Frank Mayhar, John Stultz On Wed, Jul 28, 2010 at 01:09:08AM +1000, Nick Piggin wrote: > On Tue, Jul 27, 2010 at 11:18:10PM +1000, Dave Chinner wrote: > > On Tue, Jul 27, 2010 at 05:05:39PM +1000, Nick Piggin wrote: > > > On Fri, Jul 23, 2010 at 11:55:14PM +1000, Dave Chinner wrote: > > solve. The difficulty (as always) is in reliably reproducing the bad > > behaviour. > > Sure, and I didn't see any corruptions, it seems pretty stable and > scalability is better than other filesystems. I'll see if I can > give a better recipe to reproduce the 'livelock'ish behaviour. Well, stable is a good start :) > > > > fs_mark rate (thousands of files/second) > > > > 2.6.35-rc5 2.6.35-rc5-scale > > > > threads xfs ext4 xfs ext4 > > > > 1 20 39 20 39 > > > > 2 35 55 35 57 > > > > 4 60 41 57 42 > > > > 8 79 9 75 9 > > > > > > > > ext4 is getting IO bound at more than 2 threads, so apart from > > > > pointing out that XFS is 8-9x faster than ext4 at 8 thread, I'm > > > > going to ignore ext4 for the purposes of testing scalability here. > > > > > > > > For XFS w/ delayed logging, 2.6.35-rc5 is only getting to about 600% > > > > CPU and with Nick's patches it's about 650% (10% higher) for > > > > slightly lower throughput. So at this class of machine for this > > > > workload, the changes result in a slight reduction in scalability. > > > > > > I wonder if these results are stable. It's possible that changes in > > > reclaim behaviour are causing my patches to require more IO for a > > > given unit of work? > > > > More likely that's the result of using a smaller log size because it > > will require more frequent metadata pushes to make space for new > > transactions. > > I was just checking whether your numbers are stable (where you > saw some slowdown with vfs-scale patches), and what could be the > cause. I agree that running real disks could make big changes in > behaviour. Yeah, the numbers are repeatable within about +/-5%. I generally don't bother with optimisations that result in gains/losses less than that because IO benchmarks that reliably repoduce results with more precise repeatability than that are few and far between. > > FWIW, I use PCP monitoring graphs to correlate behavioural changes > > across different subsystems because it is far easier to relate > > information visually than it is by looking at raw numbers or traces. > > I think this graph shows the effect of relcaim on performance > > most clearly: > > > > http://userweb.kernel.org/~dgc/shrinker-2.6.36/fs_mark-2.6.35-rc3-context-only-per-xfs-batch6-16x500-xfs.png > > I haven't actually used that, it looks interesting. The archiving side of PCP is the most useful, I find. i.e. being able to record the metrics into a file and analyse them with pmchart or other tools after the fact... > > That is by far the largest improvement I've been able to obtain from > > modifying the shrinker code, and it is from those sorts of > > observations that I think that IO being issued from reclaim is > > currently the most significant performance limiting factor for XFS > > in this sort of workload.... > > How is the xfs inode reclaim tied to linux inode reclaim? Does the > xfs inode not become reclaimable until some time after the linux inode > is reclaimed? Or what? The struct xfs_inode embeds a struct inode like so: struct xfs_inode { ..... struct inode i_inode; } so they are the same chunk of memory. XFS does not use the VFS inode hashes for finding inodes - that's what the per-ag radix trees are used for. The xfs_inode lives longer than the struct inode because we do non-trivial work after the VFS "reclaims" the struct inode. For example, when an inode is unlinked do not truncate or free the inode until after the VFS has finished with it - the inode remains on the unlinked list (orphaned in ext3 terms) from the time is is unlinked by the VFS to the time the last VFs reference goes away. When XFS gets it, XFS then issues the inactive transaction that takes the inode off the unlinked list and marks it free in the inode alloc btree. This transaction is asynchronous and dirties the xfs inode. Finally XFS will mark the inode as reclaimable via a radix tree tag. The final processing of the inode is then done via eaither a background relcaim walk from xfssyncd (every 30s) where it will do non-blocking operations to finalіze reclaim. It may take several passes to actually reclaim the inode. e.g. one pass to force the log if the inode is pinned, another pass to flush the inode to disk if it is dirty and not stale, and then another pass to reclaim the inode once clean. There may be multiple passes inbetween where the inode is skipped because those operations have not completed. And to top it all off, if the inode is looked up again (cache hit) while in the reclaimable state, it will be removed from the reclaim state and reused immediately. in this case we don't need to continue the reclaim processing other things will ensure all the correct information will go to disk. > Do all or most of the xfs inodes require IO before being reclaimed > during this test? Yes, because all the inode are being dirtied and they are being reclaimed faster than background flushing expires them. > I wonder if you could throttle them a bit or sort > them somehow so that they tend to be cleaned by writeout and reclaim > just comes after and removes the clean ones, like pagecache reclaim > is (supposed) to work.? The whole point of using the radix trees is to get nicely sorted reclaim IO - inodes are indexed by number, and the radix tree walk gives us ascending inode number (and hence ascending block number) reclaim - and the background reclaim allows optimal flushing to occur by aggregating all the IO into delayed write metadata buffers so they can be sorted and flushed to the elevator by the xfsbufd in the most optimal manner possible. The shrinker does preempt this somewhat, which is why delaying the XFS shrinker's work appears to improve things alot. If the shrinker is not running, the the background reclaim does exactly what you are suggesting. However, I don't think the increase in iops is caused by the XFS inode shrinker - I think that it is the VFS cache shrinkers. If you look at the the graphs in the link above, preformance doesn't decrease when the XFS inode cache is being shrunk (top chart, yellow trace) - it drops when the vfs caches are being shrunk (middle chart). I haven't correlated the behaviour any further than that because I haven't had time. FWIW, all this background reclaim, radix tree reclaim tagging and walking, embedded struct inodes, etc is all relatively new code. The oldest bit of it was introduced in 2.6.31 (I think) and so a significant part of what we are exploring here is uncharted territory. The changes to relcaim, etc are aprtially reponsible for the scalabilty we are geting from delayed logging, but there is certainly room for improvement.... Cheers, Dave. -- Dave Chinner david@fromorbit.com -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: VFS scalability git tree 2010-07-22 19:01 ` Nick Piggin @ 2010-07-23 15:35 ` Nick Piggin -1 siblings, 0 replies; 76+ messages in thread From: Nick Piggin @ 2010-07-23 15:35 UTC (permalink / raw) To: Nick Piggin, Michael Neuling Cc: linux-fsdevel, linux-kernel, linux-mm, Frank Mayhar, John Stultz On Fri, Jul 23, 2010 at 05:01:00AM +1000, Nick Piggin wrote: > I'm pleased to announce I have a git tree up of my vfs scalability work. > > git://git.kernel.org/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git > http://git.kernel.org/?p=linux/kernel/git/npiggin/linux-npiggin.git > Summary of a few numbers I've run. google's socket teardown workload > runs 3-4x faster on my 2 socket Opteron. Single thread git diff runs 20% > on same machine. 32 node Altix runs dbench on ramfs 150x faster (100MB/s > up to 15GB/s). Following post just contains some preliminary benchmark numbers on a POWER7. Boring if you're not interested in this stuff. IBM and Mikey kindly allowed me to do some test runs on a big POWER7 system today. Very is the only word I'm authorized to describe how big is big. We tested the vfs-scale-working and master branches from my git tree as of today. I'll stick with relative numbers to be safe. All tests were run on ramfs. First and very important is single threaded performance of basic code. POWER7 is obviously vastly different from a Barcelona or Nehalem. and store-free path walk uses a lot of seqlocks, which are cheap on x86, a little more epensive on others. Test case time difference, vanilla to vfs-scale (negative is better) stat() -10.8% +/- 0.3% close(open()) 4.3% +/- 0.3% unlink(creat()) 36.8% +/- 0.3% stat is significantly faster which is really good. open/close is a bit slower which we didn't get time to analyse. There are one or two seqlock checks which might be avoided, which could make up the difference. It's not horrible, but I hope to get POWER7 open/close more competitive (on x86 open/close is even a bit faster). Note this is a worst case for rcu-path-walk: lookup of "./file", because it has to take refcount on the final element. With more elements, rcu walk should gain the advantage. creat/unlink is showing the big RCU penalty. However I have penciled out a working design with Linus of how to do SLAB_DESTROY_BY_RCU. However it makes the store-free path walking and some inode RCU list walking a little bit trickier, so I prefer not to dump too much on at once. There is something that can be done if regressions show up. I don't anticipate many regressions outside microbenchmarks, and this is about the absolute worst case. On to parallel tests. Firstly, the google socket workload. Running with "NR_THREADS" children, vfs-scale patches do this: root@p7ih06:~/google# time ./google --files_per_cpu 10000 > /dev/null real 0m4.976s user 8m38.925s sys 6m45.236s root@p7ih06:~/google# time ./google --files_per_cpu 20000 > /dev/null real 0m7.816s user 11m21.034s sys 14m38.258s root@p7ih06:~/google# time ./google --files_per_cpu 40000 > /dev/null real 0m11.358s user 11m37.955s sys 28m44.911s Reducing to NR_THREADS/4 children allows vanilla to complete: root@p7ih06:~/google# time ./google --files_per_cpu 10000 real 1m23.118s user 3m31.820s sys 81m10.405s I was actually surprised it did that well. Dbench was an interesting one. We didn't manage to stretch the box's legs, unfortunately! dbench with 1 proc gave about 500MB/s, 64 procs gave 21GB/s, 128 and throughput dropped dramatically. Turns out that weird things start happening with rename seqlock versus d_lookup, and d_move contention (dbench does a sprinkle of renaming). That can be improved I think, but noth worth bothering with for the time being. It's not really worth testing vanilla at high dbench parallelism. Parallel git diff workload looked OK. It seemed to be scaling fine in the vfs, but it hit a bottlneck in powerpc's tlb invalidation, so numbers may not be so interesting. Lastly, some parallel syscall microbenchmarks: procs vanilla vfs-scale open-close, seperate-cwd 1 384557.70 355923.82 op/s/proc NR_CORES 86.63 164054.64 op/s/proc NR_THREADS 18.68 (ouch!) open-close, same-cwd 1 381074.32 339161.25 NR_CORES 104.16 107653.05 creat-unlink, seperate-cwd 1 145891.05 104301.06 NR_CORES 29.81 10061.66 creat-unlink, same-cwd 1 129681.27 104301.06 NR_CORES 12.68 181.24 So we can see the single thread performance regressions here, but the vanilla case really chokes at high CPU counts. ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: VFS scalability git tree @ 2010-07-23 15:35 ` Nick Piggin 0 siblings, 0 replies; 76+ messages in thread From: Nick Piggin @ 2010-07-23 15:35 UTC (permalink / raw) To: Nick Piggin, Michael Neuling Cc: linux-fsdevel, linux-kernel, linux-mm, Frank Mayhar, John Stultz On Fri, Jul 23, 2010 at 05:01:00AM +1000, Nick Piggin wrote: > I'm pleased to announce I have a git tree up of my vfs scalability work. > > git://git.kernel.org/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git > http://git.kernel.org/?p=linux/kernel/git/npiggin/linux-npiggin.git > Summary of a few numbers I've run. google's socket teardown workload > runs 3-4x faster on my 2 socket Opteron. Single thread git diff runs 20% > on same machine. 32 node Altix runs dbench on ramfs 150x faster (100MB/s > up to 15GB/s). Following post just contains some preliminary benchmark numbers on a POWER7. Boring if you're not interested in this stuff. IBM and Mikey kindly allowed me to do some test runs on a big POWER7 system today. Very is the only word I'm authorized to describe how big is big. We tested the vfs-scale-working and master branches from my git tree as of today. I'll stick with relative numbers to be safe. All tests were run on ramfs. First and very important is single threaded performance of basic code. POWER7 is obviously vastly different from a Barcelona or Nehalem. and store-free path walk uses a lot of seqlocks, which are cheap on x86, a little more epensive on others. Test case time difference, vanilla to vfs-scale (negative is better) stat() -10.8% +/- 0.3% close(open()) 4.3% +/- 0.3% unlink(creat()) 36.8% +/- 0.3% stat is significantly faster which is really good. open/close is a bit slower which we didn't get time to analyse. There are one or two seqlock checks which might be avoided, which could make up the difference. It's not horrible, but I hope to get POWER7 open/close more competitive (on x86 open/close is even a bit faster). Note this is a worst case for rcu-path-walk: lookup of "./file", because it has to take refcount on the final element. With more elements, rcu walk should gain the advantage. creat/unlink is showing the big RCU penalty. However I have penciled out a working design with Linus of how to do SLAB_DESTROY_BY_RCU. However it makes the store-free path walking and some inode RCU list walking a little bit trickier, so I prefer not to dump too much on at once. There is something that can be done if regressions show up. I don't anticipate many regressions outside microbenchmarks, and this is about the absolute worst case. On to parallel tests. Firstly, the google socket workload. Running with "NR_THREADS" children, vfs-scale patches do this: root@p7ih06:~/google# time ./google --files_per_cpu 10000 > /dev/null real 0m4.976s user 8m38.925s sys 6m45.236s root@p7ih06:~/google# time ./google --files_per_cpu 20000 > /dev/null real 0m7.816s user 11m21.034s sys 14m38.258s root@p7ih06:~/google# time ./google --files_per_cpu 40000 > /dev/null real 0m11.358s user 11m37.955s sys 28m44.911s Reducing to NR_THREADS/4 children allows vanilla to complete: root@p7ih06:~/google# time ./google --files_per_cpu 10000 real 1m23.118s user 3m31.820s sys 81m10.405s I was actually surprised it did that well. Dbench was an interesting one. We didn't manage to stretch the box's legs, unfortunately! dbench with 1 proc gave about 500MB/s, 64 procs gave 21GB/s, 128 and throughput dropped dramatically. Turns out that weird things start happening with rename seqlock versus d_lookup, and d_move contention (dbench does a sprinkle of renaming). That can be improved I think, but noth worth bothering with for the time being. It's not really worth testing vanilla at high dbench parallelism. Parallel git diff workload looked OK. It seemed to be scaling fine in the vfs, but it hit a bottlneck in powerpc's tlb invalidation, so numbers may not be so interesting. Lastly, some parallel syscall microbenchmarks: procs vanilla vfs-scale open-close, seperate-cwd 1 384557.70 355923.82 op/s/proc NR_CORES 86.63 164054.64 op/s/proc NR_THREADS 18.68 (ouch!) open-close, same-cwd 1 381074.32 339161.25 NR_CORES 104.16 107653.05 creat-unlink, seperate-cwd 1 145891.05 104301.06 NR_CORES 29.81 10061.66 creat-unlink, same-cwd 1 129681.27 104301.06 NR_CORES 12.68 181.24 So we can see the single thread performance regressions here, but the vanilla case really chokes at high CPU counts. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: VFS scalability git tree 2010-07-22 19:01 ` Nick Piggin @ 2010-07-24 8:43 ` KOSAKI Motohiro -1 siblings, 0 replies; 76+ messages in thread From: KOSAKI Motohiro @ 2010-07-24 8:43 UTC (permalink / raw) To: Nick Piggin Cc: kosaki.motohiro, linux-fsdevel, linux-kernel, linux-mm, Frank Mayhar, John Stultz > At this point, I would be very interested in reviewing, correctness > testing on different configurations, and of course benchmarking. I haven't review this series so long time. but I've found one misterious shrink_slab() usage. can you please see my patch? (I will send it as another mail) ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: VFS scalability git tree @ 2010-07-24 8:43 ` KOSAKI Motohiro 0 siblings, 0 replies; 76+ messages in thread From: KOSAKI Motohiro @ 2010-07-24 8:43 UTC (permalink / raw) To: Nick Piggin Cc: kosaki.motohiro, linux-fsdevel, linux-kernel, linux-mm, Frank Mayhar, John Stultz > At this point, I would be very interested in reviewing, correctness > testing on different configurations, and of course benchmarking. I haven't review this series so long time. but I've found one misterious shrink_slab() usage. can you please see my patch? (I will send it as another mail) -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 76+ messages in thread
* [PATCH 1/2] vmscan: shrink_all_slab() use reclaim_state instead the return value of shrink_slab() 2010-07-24 8:43 ` KOSAKI Motohiro (?) @ 2010-07-24 8:44 ` KOSAKI Motohiro -1 siblings, 0 replies; 76+ messages in thread From: KOSAKI Motohiro @ 2010-07-24 8:44 UTC (permalink / raw) To: Nick Piggin, linux-fsdevel, linux-kernel, linux-mm, Frank Mayhar, John Stultz Cc: kosaki.motohiro Now, shrink_slab() doesn't return number of reclaimed objects. IOW, current shrink_all_slab() is broken. Thus instead we use reclaim_state to detect no reclaimable slab objects. Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> --- mm/vmscan.c | 20 +++++++++----------- 1 files changed, 9 insertions(+), 11 deletions(-) diff --git a/mm/vmscan.c b/mm/vmscan.c index d7256e0..bfa1975 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -300,18 +300,16 @@ static unsigned long shrink_slab(struct zone *zone, unsigned long scanned, unsig void shrink_all_slab(void) { struct zone *zone; - unsigned long nr; + struct reclaim_state reclaim_state; -again: - nr = 0; - for_each_zone(zone) - nr += shrink_slab(zone, 1, 1, 1, GFP_KERNEL); - /* - * If we reclaimed less than 10 objects, might as well call - * it a day. Nothing special about the number 10. - */ - if (nr >= 10) - goto again; + current->reclaim_state = &reclaim_state; + do { + reclaim_state.reclaimed_slab = 0; + for_each_zone(zone) + shrink_slab(zone, 1, 1, 1, GFP_KERNEL); + } while (reclaim_state.reclaimed_slab); + + current->reclaim_state = NULL; } static inline int is_page_cache_freeable(struct page *page) -- 1.6.5.2 ^ permalink raw reply related [flat|nested] 76+ messages in thread
* [PATCH 1/2] vmscan: shrink_all_slab() use reclaim_state instead the return value of shrink_slab() @ 2010-07-24 8:44 ` KOSAKI Motohiro 0 siblings, 0 replies; 76+ messages in thread From: KOSAKI Motohiro @ 2010-07-24 8:44 UTC (permalink / raw) To: Nick Piggin, linux-fsdevel, linux-kernel, linux-mm, Frank Mayhar, John Stultz Cc: kosaki.motohiro Now, shrink_slab() doesn't return number of reclaimed objects. IOW, current shrink_all_slab() is broken. Thus instead we use reclaim_state to detect no reclaimable slab objects. Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> --- mm/vmscan.c | 20 +++++++++----------- 1 files changed, 9 insertions(+), 11 deletions(-) diff --git a/mm/vmscan.c b/mm/vmscan.c index d7256e0..bfa1975 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -300,18 +300,16 @@ static unsigned long shrink_slab(struct zone *zone, unsigned long scanned, unsig void shrink_all_slab(void) { struct zone *zone; - unsigned long nr; + struct reclaim_state reclaim_state; -again: - nr = 0; - for_each_zone(zone) - nr += shrink_slab(zone, 1, 1, 1, GFP_KERNEL); - /* - * If we reclaimed less than 10 objects, might as well call - * it a day. Nothing special about the number 10. - */ - if (nr >= 10) - goto again; + current->reclaim_state = &reclaim_state; + do { + reclaim_state.reclaimed_slab = 0; + for_each_zone(zone) + shrink_slab(zone, 1, 1, 1, GFP_KERNEL); + } while (reclaim_state.reclaimed_slab); + + current->reclaim_state = NULL; } static inline int is_page_cache_freeable(struct page *page) -- 1.6.5.2 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply related [flat|nested] 76+ messages in thread
* [PATCH 1/2] vmscan: shrink_all_slab() use reclaim_state instead the return value of shrink_slab() @ 2010-07-24 8:44 ` KOSAKI Motohiro 0 siblings, 0 replies; 76+ messages in thread From: KOSAKI Motohiro @ 2010-07-24 8:44 UTC (permalink / raw) To: Nick Piggin, linux-fsdevel, linux-kernel, linux-mm, Frank Mayhar, John Stultz Cc: kosaki.motohiro Now, shrink_slab() doesn't return number of reclaimed objects. IOW, current shrink_all_slab() is broken. Thus instead we use reclaim_state to detect no reclaimable slab objects. Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> --- mm/vmscan.c | 20 +++++++++----------- 1 files changed, 9 insertions(+), 11 deletions(-) diff --git a/mm/vmscan.c b/mm/vmscan.c index d7256e0..bfa1975 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -300,18 +300,16 @@ static unsigned long shrink_slab(struct zone *zone, unsigned long scanned, unsig void shrink_all_slab(void) { struct zone *zone; - unsigned long nr; + struct reclaim_state reclaim_state; -again: - nr = 0; - for_each_zone(zone) - nr += shrink_slab(zone, 1, 1, 1, GFP_KERNEL); - /* - * If we reclaimed less than 10 objects, might as well call - * it a day. Nothing special about the number 10. - */ - if (nr >= 10) - goto again; + current->reclaim_state = &reclaim_state; + do { + reclaim_state.reclaimed_slab = 0; + for_each_zone(zone) + shrink_slab(zone, 1, 1, 1, GFP_KERNEL); + } while (reclaim_state.reclaimed_slab); + + current->reclaim_state = NULL; } static inline int is_page_cache_freeable(struct page *page) -- 1.6.5.2 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply related [flat|nested] 76+ messages in thread
* Re: [PATCH 1/2] vmscan: shrink_all_slab() use reclaim_state instead the return value of shrink_slab() 2010-07-24 8:44 ` KOSAKI Motohiro @ 2010-07-24 12:05 ` KOSAKI Motohiro -1 siblings, 0 replies; 76+ messages in thread From: KOSAKI Motohiro @ 2010-07-24 12:05 UTC (permalink / raw) To: Nick Piggin, linux-fsdevel, linux-kernel, linux-mm, Frank Mayhar, John Stultz Cc: kosaki.motohiro 2010/7/24 KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>: > Now, shrink_slab() doesn't return number of reclaimed objects. IOW, > current shrink_all_slab() is broken. Thus instead we use reclaim_state > to detect no reclaimable slab objects. > > Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> > --- > mm/vmscan.c | 20 +++++++++----------- > 1 files changed, 9 insertions(+), 11 deletions(-) > > diff --git a/mm/vmscan.c b/mm/vmscan.c > index d7256e0..bfa1975 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -300,18 +300,16 @@ static unsigned long shrink_slab(struct zone *zone, unsigned long scanned, unsig > void shrink_all_slab(void) > { > struct zone *zone; > - unsigned long nr; > + struct reclaim_state reclaim_state; > > -again: > - nr = 0; > - for_each_zone(zone) > - nr += shrink_slab(zone, 1, 1, 1, GFP_KERNEL); > - /* > - * If we reclaimed less than 10 objects, might as well call > - * it a day. Nothing special about the number 10. > - */ > - if (nr >= 10) > - goto again; > + current->reclaim_state = &reclaim_state; > + do { > + reclaim_state.reclaimed_slab = 0; > + for_each_zone(zone) Oops, this should be for_each_populated_zone(). > + shrink_slab(zone, 1, 1, 1, GFP_KERNEL); > + } while (reclaim_state.reclaimed_slab); > + > + current->reclaim_state = NULL; > } > > static inline int is_page_cache_freeable(struct page *page) > -- > 1.6.5.2 > > > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> > ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 1/2] vmscan: shrink_all_slab() use reclaim_state instead the return value of shrink_slab() @ 2010-07-24 12:05 ` KOSAKI Motohiro 0 siblings, 0 replies; 76+ messages in thread From: KOSAKI Motohiro @ 2010-07-24 12:05 UTC (permalink / raw) To: Nick Piggin, linux-fsdevel, linux-kernel, linux-mm, Frank Mayhar, John Stultz Cc: kosaki.motohiro 2010/7/24 KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>: > Now, shrink_slab() doesn't return number of reclaimed objects. IOW, > current shrink_all_slab() is broken. Thus instead we use reclaim_state > to detect no reclaimable slab objects. > > Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> > --- > mm/vmscan.c | 20 +++++++++----------- > 1 files changed, 9 insertions(+), 11 deletions(-) > > diff --git a/mm/vmscan.c b/mm/vmscan.c > index d7256e0..bfa1975 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -300,18 +300,16 @@ static unsigned long shrink_slab(struct zone *zone, unsigned long scanned, unsig > void shrink_all_slab(void) > { > struct zone *zone; > - unsigned long nr; > + struct reclaim_state reclaim_state; > > -again: > - nr = 0; > - for_each_zone(zone) > - nr += shrink_slab(zone, 1, 1, 1, GFP_KERNEL); > - /* > - * If we reclaimed less than 10 objects, might as well call > - * it a day. Nothing special about the number 10. > - */ > - if (nr >= 10) > - goto again; > + current->reclaim_state = &reclaim_state; > + do { > + reclaim_state.reclaimed_slab = 0; > + for_each_zone(zone) Oops, this should be for_each_populated_zone(). > + shrink_slab(zone, 1, 1, 1, GFP_KERNEL); > + } while (reclaim_state.reclaimed_slab); > + > + current->reclaim_state = NULL; > } > > static inline int is_page_cache_freeable(struct page *page) > -- > 1.6.5.2 > > > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 76+ messages in thread
* [PATCH 2/2] vmscan: change shrink_slab() return tyep with void 2010-07-24 8:43 ` KOSAKI Motohiro (?) @ 2010-07-24 8:46 ` KOSAKI Motohiro -1 siblings, 0 replies; 76+ messages in thread From: KOSAKI Motohiro @ 2010-07-24 8:46 UTC (permalink / raw) To: Nick Piggin, linux-fsdevel, linux-kernel, linux-mm, Frank Mayhar, John Stultz Cc: kosaki.motohiro Now, no caller use the return value of shrink_slab(). Thus we can change it with void. Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> --- mm/vmscan.c | 7 +++---- 1 files changed, 3 insertions(+), 4 deletions(-) diff --git a/mm/vmscan.c b/mm/vmscan.c index bfa1975..89b593e 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -277,24 +277,23 @@ EXPORT_SYMBOL(shrinker_do_scan); * * Returns the number of slab objects which we shrunk. */ -static unsigned long shrink_slab(struct zone *zone, unsigned long scanned, unsigned long total, +static void shrink_slab(struct zone *zone, unsigned long scanned, unsigned long total, unsigned long global, gfp_t gfp_mask) { struct shrinker *shrinker; - unsigned long ret = 0; if (scanned == 0) scanned = SWAP_CLUSTER_MAX; if (!down_read_trylock(&shrinker_rwsem)) - return 1; /* Assume we'll be able to shrink next time */ + return; list_for_each_entry(shrinker, &shrinker_list, list) { (*shrinker->shrink)(shrinker, zone, scanned, total, global, gfp_mask); } up_read(&shrinker_rwsem); - return ret; + return; } void shrink_all_slab(void) -- 1.6.5.2 ^ permalink raw reply related [flat|nested] 76+ messages in thread
* [PATCH 2/2] vmscan: change shrink_slab() return tyep with void @ 2010-07-24 8:46 ` KOSAKI Motohiro 0 siblings, 0 replies; 76+ messages in thread From: KOSAKI Motohiro @ 2010-07-24 8:46 UTC (permalink / raw) To: Nick Piggin, linux-fsdevel, linux-kernel, linux-mm, Frank Mayhar, John Stultz Cc: kosaki.motohiro Now, no caller use the return value of shrink_slab(). Thus we can change it with void. Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> --- mm/vmscan.c | 7 +++---- 1 files changed, 3 insertions(+), 4 deletions(-) diff --git a/mm/vmscan.c b/mm/vmscan.c index bfa1975..89b593e 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -277,24 +277,23 @@ EXPORT_SYMBOL(shrinker_do_scan); * * Returns the number of slab objects which we shrunk. */ -static unsigned long shrink_slab(struct zone *zone, unsigned long scanned, unsigned long total, +static void shrink_slab(struct zone *zone, unsigned long scanned, unsigned long total, unsigned long global, gfp_t gfp_mask) { struct shrinker *shrinker; - unsigned long ret = 0; if (scanned == 0) scanned = SWAP_CLUSTER_MAX; if (!down_read_trylock(&shrinker_rwsem)) - return 1; /* Assume we'll be able to shrink next time */ + return; list_for_each_entry(shrinker, &shrinker_list, list) { (*shrinker->shrink)(shrinker, zone, scanned, total, global, gfp_mask); } up_read(&shrinker_rwsem); - return ret; + return; } void shrink_all_slab(void) -- 1.6.5.2 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply related [flat|nested] 76+ messages in thread
* [PATCH 2/2] vmscan: change shrink_slab() return tyep with void @ 2010-07-24 8:46 ` KOSAKI Motohiro 0 siblings, 0 replies; 76+ messages in thread From: KOSAKI Motohiro @ 2010-07-24 8:46 UTC (permalink / raw) To: Nick Piggin, linux-fsdevel, linux-kernel, linux-mm, Frank Mayhar, John Stultz Cc: kosaki.motohiro Now, no caller use the return value of shrink_slab(). Thus we can change it with void. Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> --- mm/vmscan.c | 7 +++---- 1 files changed, 3 insertions(+), 4 deletions(-) diff --git a/mm/vmscan.c b/mm/vmscan.c index bfa1975..89b593e 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -277,24 +277,23 @@ EXPORT_SYMBOL(shrinker_do_scan); * * Returns the number of slab objects which we shrunk. */ -static unsigned long shrink_slab(struct zone *zone, unsigned long scanned, unsigned long total, +static void shrink_slab(struct zone *zone, unsigned long scanned, unsigned long total, unsigned long global, gfp_t gfp_mask) { struct shrinker *shrinker; - unsigned long ret = 0; if (scanned == 0) scanned = SWAP_CLUSTER_MAX; if (!down_read_trylock(&shrinker_rwsem)) - return 1; /* Assume we'll be able to shrink next time */ + return; list_for_each_entry(shrinker, &shrinker_list, list) { (*shrinker->shrink)(shrinker, zone, scanned, total, global, gfp_mask); } up_read(&shrinker_rwsem); - return ret; + return; } void shrink_all_slab(void) -- 1.6.5.2 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply related [flat|nested] 76+ messages in thread
* Re: VFS scalability git tree 2010-07-24 8:43 ` KOSAKI Motohiro @ 2010-07-24 10:54 ` KOSAKI Motohiro -1 siblings, 0 replies; 76+ messages in thread From: KOSAKI Motohiro @ 2010-07-24 10:54 UTC (permalink / raw) To: Nick Piggin Cc: kosaki.motohiro, linux-fsdevel, linux-kernel, linux-mm, Frank Mayhar, John Stultz > > At this point, I would be very interested in reviewing, correctness > > testing on different configurations, and of course benchmarking. > > I haven't review this series so long time. but I've found one misterious > shrink_slab() usage. can you please see my patch? (I will send it as > another mail) Plus, I have one question. upstream shrink_slab() calculation and your calculation have bigger change rather than your patch description explained. upstream: shrink_slab() lru_scanned max_pass basic_scan_objects = 4 x ------------- x ----------------------------- lru_pages shrinker->seeks (default:2) scan_objects = min(basic_scan_objects, max_pass * 2) shrink_icache_memory() sysctl_vfs_cache_pressure max_pass = inodes_stat.nr_unused x -------------------------- 100 That said, higher sysctl_vfs_cache_pressure makes higher slab reclaim. In the other hand, your code: shrinker_add_scan() scanned objects scan_objects = 4 x ------------- x ----------- x SHRINK_FACTOR x SHRINK_FACTOR total ratio shrink_icache_memory() ratio = DEFAULT_SEEKS * sysctl_vfs_cache_pressure / 100 That said, higher sysctl_vfs_cache_pressure makes smaller slab reclaim. So, I guess following change honorly refrect your original intention. New calculation is, shrinker_add_scan() scanned scan_objects = ------------- x objects x ratio total shrink_icache_memory() ratio = DEFAULT_SEEKS * sysctl_vfs_cache_pressure / 100 This has the same behavior as upstream. because upstream's 4/shrinker->seeks = 2. also the above has DEFAULT_SEEKS = SHRINK_FACTORx2. =============== o move 'ratio' from denominator to numerator o adapt kvm/mmu_shrink o SHRINK_FACTOR / 2 (default seek) x 4 (unknown shrink slab modifier) -> (SHRINK_FACTOR*2) == DEFAULT_SEEKS --- arch/x86/kvm/mmu.c | 2 +- mm/vmscan.c | 10 ++-------- 2 files changed, 3 insertions(+), 9 deletions(-) diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c index ae5a038..cea1e92 100644 --- a/arch/x86/kvm/mmu.c +++ b/arch/x86/kvm/mmu.c @@ -2942,7 +2942,7 @@ static int mmu_shrink(struct shrinker *shrink, } shrinker_add_scan(&nr_to_scan, scanned, global, cache_count, - DEFAULT_SEEKS*10); + DEFAULT_SEEKS/10); done: cache_count = shrinker_do_scan(&nr_to_scan, SHRINK_BATCH); diff --git a/mm/vmscan.c b/mm/vmscan.c index 89b593e..2d8e9ab 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -208,14 +208,8 @@ void shrinker_add_scan(unsigned long *dst, { unsigned long long delta; - /* - * The constant 4 comes from old code. Who knows why. - * This could all use a good tune up with some decent - * benchmarks and numbers. - */ - delta = (unsigned long long)scanned * objects - * SHRINK_FACTOR * SHRINK_FACTOR * 4UL; - do_div(delta, (ratio * total + 1)); + delta = (unsigned long long)scanned * objects * ratio; + do_div(delta, total+ 1); /* * Avoid risking looping forever due to too large nr value: -- 1.6.5.2 ^ permalink raw reply related [flat|nested] 76+ messages in thread
* Re: VFS scalability git tree @ 2010-07-24 10:54 ` KOSAKI Motohiro 0 siblings, 0 replies; 76+ messages in thread From: KOSAKI Motohiro @ 2010-07-24 10:54 UTC (permalink / raw) To: Nick Piggin Cc: kosaki.motohiro, linux-fsdevel, linux-kernel, linux-mm, Frank Mayhar, John Stultz > > At this point, I would be very interested in reviewing, correctness > > testing on different configurations, and of course benchmarking. > > I haven't review this series so long time. but I've found one misterious > shrink_slab() usage. can you please see my patch? (I will send it as > another mail) Plus, I have one question. upstream shrink_slab() calculation and your calculation have bigger change rather than your patch description explained. upstream: shrink_slab() lru_scanned max_pass basic_scan_objects = 4 x ------------- x ----------------------------- lru_pages shrinker->seeks (default:2) scan_objects = min(basic_scan_objects, max_pass * 2) shrink_icache_memory() sysctl_vfs_cache_pressure max_pass = inodes_stat.nr_unused x -------------------------- 100 That said, higher sysctl_vfs_cache_pressure makes higher slab reclaim. In the other hand, your code: shrinker_add_scan() scanned objects scan_objects = 4 x ------------- x ----------- x SHRINK_FACTOR x SHRINK_FACTOR total ratio shrink_icache_memory() ratio = DEFAULT_SEEKS * sysctl_vfs_cache_pressure / 100 That said, higher sysctl_vfs_cache_pressure makes smaller slab reclaim. So, I guess following change honorly refrect your original intention. New calculation is, shrinker_add_scan() scanned scan_objects = ------------- x objects x ratio total shrink_icache_memory() ratio = DEFAULT_SEEKS * sysctl_vfs_cache_pressure / 100 This has the same behavior as upstream. because upstream's 4/shrinker->seeks = 2. also the above has DEFAULT_SEEKS = SHRINK_FACTORx2. =============== o move 'ratio' from denominator to numerator o adapt kvm/mmu_shrink o SHRINK_FACTOR / 2 (default seek) x 4 (unknown shrink slab modifier) -> (SHRINK_FACTOR*2) == DEFAULT_SEEKS --- arch/x86/kvm/mmu.c | 2 +- mm/vmscan.c | 10 ++-------- 2 files changed, 3 insertions(+), 9 deletions(-) diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c index ae5a038..cea1e92 100644 --- a/arch/x86/kvm/mmu.c +++ b/arch/x86/kvm/mmu.c @@ -2942,7 +2942,7 @@ static int mmu_shrink(struct shrinker *shrink, } shrinker_add_scan(&nr_to_scan, scanned, global, cache_count, - DEFAULT_SEEKS*10); + DEFAULT_SEEKS/10); done: cache_count = shrinker_do_scan(&nr_to_scan, SHRINK_BATCH); diff --git a/mm/vmscan.c b/mm/vmscan.c index 89b593e..2d8e9ab 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -208,14 +208,8 @@ void shrinker_add_scan(unsigned long *dst, { unsigned long long delta; - /* - * The constant 4 comes from old code. Who knows why. - * This could all use a good tune up with some decent - * benchmarks and numbers. - */ - delta = (unsigned long long)scanned * objects - * SHRINK_FACTOR * SHRINK_FACTOR * 4UL; - do_div(delta, (ratio * total + 1)); + delta = (unsigned long long)scanned * objects * ratio; + do_div(delta, total+ 1); /* * Avoid risking looping forever due to too large nr value: -- 1.6.5.2 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply related [flat|nested] 76+ messages in thread
* Re: VFS scalability git tree 2010-07-22 19:01 ` Nick Piggin @ 2010-07-26 5:41 ` Nick Piggin -1 siblings, 0 replies; 76+ messages in thread From: Nick Piggin @ 2010-07-26 5:41 UTC (permalink / raw) To: linux-fsdevel Cc: linux-kernel, linux-mm, Frank Mayhar, John Stultz, Dave Chinner, KOSAKI Motohiro, Michael Neuling On Fri, Jul 23, 2010 at 05:01:00AM +1000, Nick Piggin wrote: > I'm pleased to announce I have a git tree up of my vfs scalability work. > > git://git.kernel.org/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git > http://git.kernel.org/?p=linux/kernel/git/npiggin/linux-npiggin.git Pushed several fixes and improvements o XFS bugs fixed by Dave o dentry and inode stats bugs noticed by Dave o vmscan shrinker bugs fixed by KOSAKI san o compile bugs noticed by John o a few attempts to improve powerpc performance (eg. reducing smp_rmb()) o scalability improvments for rename_lock ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: VFS scalability git tree @ 2010-07-26 5:41 ` Nick Piggin 0 siblings, 0 replies; 76+ messages in thread From: Nick Piggin @ 2010-07-26 5:41 UTC (permalink / raw) To: linux-fsdevel Cc: linux-kernel, linux-mm, Frank Mayhar, John Stultz, Dave Chinner, KOSAKI Motohiro, Michael Neuling On Fri, Jul 23, 2010 at 05:01:00AM +1000, Nick Piggin wrote: > I'm pleased to announce I have a git tree up of my vfs scalability work. > > git://git.kernel.org/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git > http://git.kernel.org/?p=linux/kernel/git/npiggin/linux-npiggin.git Pushed several fixes and improvements o XFS bugs fixed by Dave o dentry and inode stats bugs noticed by Dave o vmscan shrinker bugs fixed by KOSAKI san o compile bugs noticed by John o a few attempts to improve powerpc performance (eg. reducing smp_rmb()) o scalability improvments for rename_lock -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: VFS scalability git tree 2010-07-26 5:41 ` Nick Piggin @ 2010-07-28 10:24 ` Nick Piggin -1 siblings, 0 replies; 76+ messages in thread From: Nick Piggin @ 2010-07-28 10:24 UTC (permalink / raw) To: Nick Piggin Cc: linux-fsdevel, linux-kernel, linux-mm, Frank Mayhar, John Stultz, Dave Chinner, KOSAKI Motohiro, Michael Neuling On Mon, Jul 26, 2010 at 03:41:11PM +1000, Nick Piggin wrote: > On Fri, Jul 23, 2010 at 05:01:00AM +1000, Nick Piggin wrote: > > I'm pleased to announce I have a git tree up of my vfs scalability work. > > > > git://git.kernel.org/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git > > http://git.kernel.org/?p=linux/kernel/git/npiggin/linux-npiggin.git > > Pushed several fixes and improvements > o XFS bugs fixed by Dave > o dentry and inode stats bugs noticed by Dave > o vmscan shrinker bugs fixed by KOSAKI san > o compile bugs noticed by John > o a few attempts to improve powerpc performance (eg. reducing smp_rmb()) > o scalability improvments for rename_lock Yet another result on my small 2s8c Opteron. This time, the re-aim benchmark configured as described here: http://ertos.nicta.com.au/publications/papers/Chubb_Williams_05.pdf It is using ext2 on ramdisk and an IO intensive workload, with fsync activity. I did 10 runs on each, and took the max jobs/sec of each run. N Min Max Median Avg Stddev x 10 2598750 2735122 2665384.6 2653353.8 46421.696 + 10 3337297.3 3484687.5 3410689.7 3397763.8 49994.631 Difference at 95.0% confidence 744410 +/- 45327.3 28.0554% +/- 1.7083% Average is 2653K jobs/s for vanilla, versus 3398K jobs/s for vfs-scalem or 28% speedup. The profile is interesting. It is known to be inode_lock intensive, but we also see here that it is do_lookup intensive, due to cacheline bouncing in common elements of path lookups. Vanilla: # Overhead Symbol # ........ ...... # 7.63% [k] __d_lookup | |--88.59%-- do_lookup |--9.75%-- __lookup_hash |--0.89%-- d_lookup 7.17% [k] _raw_spin_lock | |--11.07%-- _atomic_dec_and_lock | | | |--53.73%-- dput | --46.27%-- iput | |--9.85%-- __mark_inode_dirty | | | |--46.25%-- ext2_new_inode | |--25.32%-- __set_page_dirty | |--18.27%-- nobh_write_end | |--6.91%-- ext2_new_blocks | |--3.12%-- ext2_unlink | |--7.69%-- ext2_new_inode | |--6.84%-- insert_inode_locked | ext2_new_inode | |--6.56%-- new_inode | ext2_new_inode | |--5.61%-- writeback_single_inode | sync_inode | generic_file_fsync | ext2_fsync | |--5.13%-- dput |--3.75%-- generic_delete_inode |--3.56%-- __d_lookup |--3.53%-- ext2_free_inode |--3.40%-- sync_inode |--2.71%-- d_instantiate |--2.36%-- d_delete |--2.25%-- inode_sub_bytes |--1.84%-- file_move |--1.52%-- file_kill |--1.36%-- ext2_new_blocks |--1.34%-- ext2_create |--1.34%-- d_alloc |--1.11%-- do_lookup |--1.07%-- iput |--1.05%-- __d_instantiate 4.19% [k] mutex_spin_on_owner | |--99.92%-- __mutex_lock_slowpath | mutex_lock | | | |--56.45%-- do_unlinkat | | sys_unlink | | | --43.55%-- do_last | do_filp_open 2.96% [k] _atomic_dec_and_lock | |--58.18%-- dput |--31.02%-- mntput_no_expire |--3.30%-- path_put |--3.09%-- iput |--2.69%-- link_path_walk |--1.02%-- fput 2.73% [k] copy_user_generic_string 2.67% [k] __mark_inode_dirty 2.65% [k] link_path_walk 2.63% [k] mark_buffer_dirty 1.72% [k] __memcpy 1.62% [k] generic_getxattr 1.50% [k] acl_permission_check 1.30% [k] __find_get_block 1.30% [k] __memset 1.17% [k] ext2_find_entry 1.09% [k] ext2_new_inode 1.06% [k] system_call 1.01% [k] kmem_cache_free 1.00% [k] dput In vfs-scale, most of the spinlock contention and path lookup cost is gone. Contention for parent i_mutex (and d_lock) for creat/unlink operations is now at the top of the profile. A lot of the spinlock overhead seems to be not contention so much as the the cost of the atomics. Down at 3% it is much less a problem than it was though. We may run into a bit of contention on the per-bdi inode dirty/io list lock, with just a single ramdisk device (dirty/fsync activity will hit this lock), but it is really not worth worrying about at the moment. # Overhead Symbol # ........ ...... # 5.67% [k] mutex_spin_on_owner | |--99.96%-- __mutex_lock_slowpath | mutex_lock | | | |--58.63%-- do_unlinkat | | sys_unlink | | | --41.37%-- do_last | do_filp_open 3.93% [k] __mark_inode_dirty 3.43% [k] copy_user_generic_string 3.31% [k] link_path_walk 3.15% [k] mark_buffer_dirty 3.11% [k] _raw_spin_lock | |--11.03%-- __mark_inode_dirty |--10.54%-- ext2_new_inode |--7.60%-- ext2_free_inode |--6.33%-- inode_sub_bytes |--6.27%-- ext2_new_blocks |--5.80%-- generic_delete_inode |--4.09%-- ext2_create |--3.62%-- writeback_single_inode |--2.92%-- sync_inode |--2.81%-- generic_drop_inode |--2.46%-- iput |--1.86%-- dput |--1.80%-- __dquot_alloc_space |--1.61%-- __mutex_unlock_slowpath |--1.59%-- generic_file_fsync |--1.57%-- __d_instantiate |--1.55%-- __set_page_dirty_buffers |--1.36%-- d_alloc_and_lookup |--1.23%-- do_path_lookup |--1.10%-- ext2_free_blocks 2.13% [k] __memset 2.12% [k] __memcpy 1.98% [k] __d_lookup_rcu 1.46% [k] generic_getxattr 1.44% [k] ext2_find_entry 1.41% [k] __find_get_block 1.27% [k] kmem_cache_free 1.25% [k] ext2_new_inode 1.23% [k] system_call 1.02% [k] ext2_add_link 1.01% [k] strncpy_from_user 0.96% [k] kmem_cache_alloc 0.95% [k] find_get_page 0.94% [k] sysret_check 0.88% [k] __d_lookup 0.75% [k] ext2_delete_entry 0.70% [k] generic_file_aio_read 0.67% [k] generic_file_buffered_write 0.63% [k] ext2_new_blocks 0.62% [k] __percpu_counter_add 0.59% [k] __bread 0.58% [k] __wake_up_bit 0.58% [k] __mutex_lock_slowpath 0.56% [k] __ext2_write_inode 0.55% [k] ext2_get_blocks ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: VFS scalability git tree @ 2010-07-28 10:24 ` Nick Piggin 0 siblings, 0 replies; 76+ messages in thread From: Nick Piggin @ 2010-07-28 10:24 UTC (permalink / raw) To: Nick Piggin Cc: linux-fsdevel, linux-kernel, linux-mm, Frank Mayhar, John Stultz, Dave Chinner, KOSAKI Motohiro, Michael Neuling On Mon, Jul 26, 2010 at 03:41:11PM +1000, Nick Piggin wrote: > On Fri, Jul 23, 2010 at 05:01:00AM +1000, Nick Piggin wrote: > > I'm pleased to announce I have a git tree up of my vfs scalability work. > > > > git://git.kernel.org/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git > > http://git.kernel.org/?p=linux/kernel/git/npiggin/linux-npiggin.git > > Pushed several fixes and improvements > o XFS bugs fixed by Dave > o dentry and inode stats bugs noticed by Dave > o vmscan shrinker bugs fixed by KOSAKI san > o compile bugs noticed by John > o a few attempts to improve powerpc performance (eg. reducing smp_rmb()) > o scalability improvments for rename_lock Yet another result on my small 2s8c Opteron. This time, the re-aim benchmark configured as described here: http://ertos.nicta.com.au/publications/papers/Chubb_Williams_05.pdf It is using ext2 on ramdisk and an IO intensive workload, with fsync activity. I did 10 runs on each, and took the max jobs/sec of each run. N Min Max Median Avg Stddev x 10 2598750 2735122 2665384.6 2653353.8 46421.696 + 10 3337297.3 3484687.5 3410689.7 3397763.8 49994.631 Difference at 95.0% confidence 744410 +/- 45327.3 28.0554% +/- 1.7083% Average is 2653K jobs/s for vanilla, versus 3398K jobs/s for vfs-scalem or 28% speedup. The profile is interesting. It is known to be inode_lock intensive, but we also see here that it is do_lookup intensive, due to cacheline bouncing in common elements of path lookups. Vanilla: # Overhead Symbol # ........ ...... # 7.63% [k] __d_lookup | |--88.59%-- do_lookup |--9.75%-- __lookup_hash |--0.89%-- d_lookup 7.17% [k] _raw_spin_lock | |--11.07%-- _atomic_dec_and_lock | | | |--53.73%-- dput | --46.27%-- iput | |--9.85%-- __mark_inode_dirty | | | |--46.25%-- ext2_new_inode | |--25.32%-- __set_page_dirty | |--18.27%-- nobh_write_end | |--6.91%-- ext2_new_blocks | |--3.12%-- ext2_unlink | |--7.69%-- ext2_new_inode | |--6.84%-- insert_inode_locked | ext2_new_inode | |--6.56%-- new_inode | ext2_new_inode | |--5.61%-- writeback_single_inode | sync_inode | generic_file_fsync | ext2_fsync | |--5.13%-- dput |--3.75%-- generic_delete_inode |--3.56%-- __d_lookup |--3.53%-- ext2_free_inode |--3.40%-- sync_inode |--2.71%-- d_instantiate |--2.36%-- d_delete |--2.25%-- inode_sub_bytes |--1.84%-- file_move |--1.52%-- file_kill |--1.36%-- ext2_new_blocks |--1.34%-- ext2_create |--1.34%-- d_alloc |--1.11%-- do_lookup |--1.07%-- iput |--1.05%-- __d_instantiate 4.19% [k] mutex_spin_on_owner | |--99.92%-- __mutex_lock_slowpath | mutex_lock | | | |--56.45%-- do_unlinkat | | sys_unlink | | | --43.55%-- do_last | do_filp_open 2.96% [k] _atomic_dec_and_lock | |--58.18%-- dput |--31.02%-- mntput_no_expire |--3.30%-- path_put |--3.09%-- iput |--2.69%-- link_path_walk |--1.02%-- fput 2.73% [k] copy_user_generic_string 2.67% [k] __mark_inode_dirty 2.65% [k] link_path_walk 2.63% [k] mark_buffer_dirty 1.72% [k] __memcpy 1.62% [k] generic_getxattr 1.50% [k] acl_permission_check 1.30% [k] __find_get_block 1.30% [k] __memset 1.17% [k] ext2_find_entry 1.09% [k] ext2_new_inode 1.06% [k] system_call 1.01% [k] kmem_cache_free 1.00% [k] dput In vfs-scale, most of the spinlock contention and path lookup cost is gone. Contention for parent i_mutex (and d_lock) for creat/unlink operations is now at the top of the profile. A lot of the spinlock overhead seems to be not contention so much as the the cost of the atomics. Down at 3% it is much less a problem than it was though. We may run into a bit of contention on the per-bdi inode dirty/io list lock, with just a single ramdisk device (dirty/fsync activity will hit this lock), but it is really not worth worrying about at the moment. # Overhead Symbol # ........ ...... # 5.67% [k] mutex_spin_on_owner | |--99.96%-- __mutex_lock_slowpath | mutex_lock | | | |--58.63%-- do_unlinkat | | sys_unlink | | | --41.37%-- do_last | do_filp_open 3.93% [k] __mark_inode_dirty 3.43% [k] copy_user_generic_string 3.31% [k] link_path_walk 3.15% [k] mark_buffer_dirty 3.11% [k] _raw_spin_lock | |--11.03%-- __mark_inode_dirty |--10.54%-- ext2_new_inode |--7.60%-- ext2_free_inode |--6.33%-- inode_sub_bytes |--6.27%-- ext2_new_blocks |--5.80%-- generic_delete_inode |--4.09%-- ext2_create |--3.62%-- writeback_single_inode |--2.92%-- sync_inode |--2.81%-- generic_drop_inode |--2.46%-- iput |--1.86%-- dput |--1.80%-- __dquot_alloc_space |--1.61%-- __mutex_unlock_slowpath |--1.59%-- generic_file_fsync |--1.57%-- __d_instantiate |--1.55%-- __set_page_dirty_buffers |--1.36%-- d_alloc_and_lookup |--1.23%-- do_path_lookup |--1.10%-- ext2_free_blocks 2.13% [k] __memset 2.12% [k] __memcpy 1.98% [k] __d_lookup_rcu 1.46% [k] generic_getxattr 1.44% [k] ext2_find_entry 1.41% [k] __find_get_block 1.27% [k] kmem_cache_free 1.25% [k] ext2_new_inode 1.23% [k] system_call 1.02% [k] ext2_add_link 1.01% [k] strncpy_from_user 0.96% [k] kmem_cache_alloc 0.95% [k] find_get_page 0.94% [k] sysret_check 0.88% [k] __d_lookup 0.75% [k] ext2_delete_entry 0.70% [k] generic_file_aio_read 0.67% [k] generic_file_buffered_write 0.63% [k] ext2_new_blocks 0.62% [k] __percpu_counter_add 0.59% [k] __bread 0.58% [k] __wake_up_bit 0.58% [k] __mutex_lock_slowpath 0.56% [k] __ext2_write_inode 0.55% [k] ext2_get_blocks -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: VFS scalability git tree 2010-07-22 19:01 ` Nick Piggin @ 2010-07-30 9:12 ` Nick Piggin -1 siblings, 0 replies; 76+ messages in thread From: Nick Piggin @ 2010-07-30 9:12 UTC (permalink / raw) To: Nick Piggin Cc: linux-fsdevel, linux-kernel, linux-mm, Frank Mayhar, John Stultz On Fri, Jul 23, 2010 at 05:01:00AM +1000, Nick Piggin wrote: > I'm pleased to announce I have a git tree up of my vfs scalability work. > > git://git.kernel.org/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git > http://git.kernel.org/?p=linux/kernel/git/npiggin/linux-npiggin.git > > Branch vfs-scale-working > > The really interesting new item is the store-free path walk, (43fe2b) > which I've re-introduced. It has had a complete redesign, it has much > better performance and scalability in more cases, and is actually sane > code now. Things are progressing well here with fixes and improvements to the branch. One thing that has been brought to my attention is that store-free path walking (rcu-walk) drops into the normal refcounted walking on any filesystem that has posix ACLs enabled. Having misread that IS_POSIXACL is based on a superblock flag, I had thought we only drop out of rcu-walk in case of encountering an inode that actually has acls. This is quite an important point for any performance testing work. ACLs can actually be rcu checked quite easily in most cases, but it takes a bit of work on APIs. Filesystems defining their own ->permission and ->d_revalidate will also not use rcu-walk. These could likewise be made to support rcu-walk more widely, but it will require knowledge of rcu-walk to be pushed into filesystems. It's not a big deal, basically: no blocking, no stores, no referencing non-rcu-protected data, and confirm with seqlock. That is usually the case in fastpaths. If it cannot be satisfied, then just return -ECHILD and you'll get called in the usual ref-walk mode next time. But for now, keep this in mind if you plan to do any serious performance testing work, *do not mount filesystems with ACL support*. Thanks, Nick ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: VFS scalability git tree @ 2010-07-30 9:12 ` Nick Piggin 0 siblings, 0 replies; 76+ messages in thread From: Nick Piggin @ 2010-07-30 9:12 UTC (permalink / raw) To: Nick Piggin Cc: linux-fsdevel, linux-kernel, linux-mm, Frank Mayhar, John Stultz On Fri, Jul 23, 2010 at 05:01:00AM +1000, Nick Piggin wrote: > I'm pleased to announce I have a git tree up of my vfs scalability work. > > git://git.kernel.org/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git > http://git.kernel.org/?p=linux/kernel/git/npiggin/linux-npiggin.git > > Branch vfs-scale-working > > The really interesting new item is the store-free path walk, (43fe2b) > which I've re-introduced. It has had a complete redesign, it has much > better performance and scalability in more cases, and is actually sane > code now. Things are progressing well here with fixes and improvements to the branch. One thing that has been brought to my attention is that store-free path walking (rcu-walk) drops into the normal refcounted walking on any filesystem that has posix ACLs enabled. Having misread that IS_POSIXACL is based on a superblock flag, I had thought we only drop out of rcu-walk in case of encountering an inode that actually has acls. This is quite an important point for any performance testing work. ACLs can actually be rcu checked quite easily in most cases, but it takes a bit of work on APIs. Filesystems defining their own ->permission and ->d_revalidate will also not use rcu-walk. These could likewise be made to support rcu-walk more widely, but it will require knowledge of rcu-walk to be pushed into filesystems. It's not a big deal, basically: no blocking, no stores, no referencing non-rcu-protected data, and confirm with seqlock. That is usually the case in fastpaths. If it cannot be satisfied, then just return -ECHILD and you'll get called in the usual ref-walk mode next time. But for now, keep this in mind if you plan to do any serious performance testing work, *do not mount filesystems with ACL support*. Thanks, Nick -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: VFS scalability git tree 2010-07-30 9:12 ` Nick Piggin (?) @ 2010-08-03 0:27 ` john stultz -1 siblings, 0 replies; 76+ messages in thread From: john stultz @ 2010-08-03 0:27 UTC (permalink / raw) To: Nick Piggin Cc: Nick Piggin, linux-fsdevel, linux-kernel, linux-mm, Frank Mayhar On Fri, 2010-07-30 at 19:12 +1000, Nick Piggin wrote: > On Fri, Jul 23, 2010 at 05:01:00AM +1000, Nick Piggin wrote: > > I'm pleased to announce I have a git tree up of my vfs scalability work. > > > > git://git.kernel.org/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git > > http://git.kernel.org/?p=linux/kernel/git/npiggin/linux-npiggin.git > > > > Branch vfs-scale-working > > > > The really interesting new item is the store-free path walk, (43fe2b) > > which I've re-introduced. It has had a complete redesign, it has much > > better performance and scalability in more cases, and is actually sane > > code now. > > Things are progressing well here with fixes and improvements to the > branch. Hey Nick, Just another minor compile issue with today's vfs-scale-working branch. fs/fuse/dir.c:231: error: ‘fuse_dentry_revalidate_rcu’ undeclared here (not in a function) >From looking at the vfat and ecryptfs changes in 582c56f032983e9a8e4b4bd6fac58d18811f7d41 it looks like you intended to add the following? diff --git a/fs/fuse/dir.c b/fs/fuse/dir.c index f0c2479..9ee4c10 100644 --- a/fs/fuse/dir.c +++ b/fs/fuse/dir.c @@ -154,7 +154,7 @@ u64 fuse_get_attr_version(struct fuse_conn *fc) * the lookup once more. If the lookup results in the same inode, * then refresh the attributes, timeouts and mark the dentry valid. */ -static int fuse_dentry_revalidate(struct dentry *entry, struct nameidata *nd) +static int fuse_dentry_revalidate_rcu(struct dentry *entry, struct nameidata *nd) { struct inode *inode = entry->d_inode; ^ permalink raw reply related [flat|nested] 76+ messages in thread
* Re: VFS scalability git tree @ 2010-08-03 0:27 ` john stultz 0 siblings, 0 replies; 76+ messages in thread From: john stultz @ 2010-08-03 0:27 UTC (permalink / raw) To: Nick Piggin Cc: Nick Piggin, linux-fsdevel, linux-kernel, linux-mm, Frank Mayhar On Fri, 2010-07-30 at 19:12 +1000, Nick Piggin wrote: > On Fri, Jul 23, 2010 at 05:01:00AM +1000, Nick Piggin wrote: > > I'm pleased to announce I have a git tree up of my vfs scalability work. > > > > git://git.kernel.org/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git > > http://git.kernel.org/?p=linux/kernel/git/npiggin/linux-npiggin.git > > > > Branch vfs-scale-working > > > > The really interesting new item is the store-free path walk, (43fe2b) > > which I've re-introduced. It has had a complete redesign, it has much > > better performance and scalability in more cases, and is actually sane > > code now. > > Things are progressing well here with fixes and improvements to the > branch. Hey Nick, Just another minor compile issue with today's vfs-scale-working branch. fs/fuse/dir.c:231: error: a??fuse_dentry_revalidate_rcua?? undeclared here (not in a function) >From looking at the vfat and ecryptfs changes in 582c56f032983e9a8e4b4bd6fac58d18811f7d41 it looks like you intended to add the following? diff --git a/fs/fuse/dir.c b/fs/fuse/dir.c index f0c2479..9ee4c10 100644 --- a/fs/fuse/dir.c +++ b/fs/fuse/dir.c @@ -154,7 +154,7 @@ u64 fuse_get_attr_version(struct fuse_conn *fc) * the lookup once more. If the lookup results in the same inode, * then refresh the attributes, timeouts and mark the dentry valid. */ -static int fuse_dentry_revalidate(struct dentry *entry, struct nameidata *nd) +static int fuse_dentry_revalidate_rcu(struct dentry *entry, struct nameidata *nd) { struct inode *inode = entry->d_inode; -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply related [flat|nested] 76+ messages in thread
* Re: VFS scalability git tree @ 2010-08-03 0:27 ` john stultz 0 siblings, 0 replies; 76+ messages in thread From: john stultz @ 2010-08-03 0:27 UTC (permalink / raw) To: Nick Piggin Cc: Nick Piggin, linux-fsdevel, linux-kernel, linux-mm, Frank Mayhar On Fri, 2010-07-30 at 19:12 +1000, Nick Piggin wrote: > On Fri, Jul 23, 2010 at 05:01:00AM +1000, Nick Piggin wrote: > > I'm pleased to announce I have a git tree up of my vfs scalability work. > > > > git://git.kernel.org/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git > > http://git.kernel.org/?p=linux/kernel/git/npiggin/linux-npiggin.git > > > > Branch vfs-scale-working > > > > The really interesting new item is the store-free path walk, (43fe2b) > > which I've re-introduced. It has had a complete redesign, it has much > > better performance and scalability in more cases, and is actually sane > > code now. > > Things are progressing well here with fixes and improvements to the > branch. Hey Nick, Just another minor compile issue with today's vfs-scale-working branch. fs/fuse/dir.c:231: error: ‘fuse_dentry_revalidate_rcu’ undeclared here (not in a function) >From looking at the vfat and ecryptfs changes in 582c56f032983e9a8e4b4bd6fac58d18811f7d41 it looks like you intended to add the following? diff --git a/fs/fuse/dir.c b/fs/fuse/dir.c index f0c2479..9ee4c10 100644 --- a/fs/fuse/dir.c +++ b/fs/fuse/dir.c @@ -154,7 +154,7 @@ u64 fuse_get_attr_version(struct fuse_conn *fc) * the lookup once more. If the lookup results in the same inode, * then refresh the attributes, timeouts and mark the dentry valid. */ -static int fuse_dentry_revalidate(struct dentry *entry, struct nameidata *nd) +static int fuse_dentry_revalidate_rcu(struct dentry *entry, struct nameidata *nd) { struct inode *inode = entry->d_inode; -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply related [flat|nested] 76+ messages in thread
* Re: VFS scalability git tree 2010-08-03 0:27 ` john stultz (?) @ 2010-08-03 5:44 ` Nick Piggin -1 siblings, 0 replies; 76+ messages in thread From: Nick Piggin @ 2010-08-03 5:44 UTC (permalink / raw) To: john stultz Cc: Nick Piggin, Nick Piggin, linux-fsdevel, linux-kernel, linux-mm, Frank Mayhar On Mon, Aug 02, 2010 at 05:27:59PM -0700, John Stultz wrote: > On Fri, 2010-07-30 at 19:12 +1000, Nick Piggin wrote: > > On Fri, Jul 23, 2010 at 05:01:00AM +1000, Nick Piggin wrote: > > > I'm pleased to announce I have a git tree up of my vfs scalability work. > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git > > > http://git.kernel.org/?p=linux/kernel/git/npiggin/linux-npiggin.git > > > > > > Branch vfs-scale-working > > > > > > The really interesting new item is the store-free path walk, (43fe2b) > > > which I've re-introduced. It has had a complete redesign, it has much > > > better performance and scalability in more cases, and is actually sane > > > code now. > > > > Things are progressing well here with fixes and improvements to the > > branch. > > Hey Nick, > Just another minor compile issue with today's vfs-scale-working branch. > > fs/fuse/dir.c:231: error: ‘fuse_dentry_revalidate_rcu’ undeclared here > (not in a function) > > >From looking at the vfat and ecryptfs changes in > 582c56f032983e9a8e4b4bd6fac58d18811f7d41 it looks like you intended to > add the following? Thanks John, you're right. I thought I actually linked and ran this, but I must not have had fuse compiled in. ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: VFS scalability git tree @ 2010-08-03 5:44 ` Nick Piggin 0 siblings, 0 replies; 76+ messages in thread From: Nick Piggin @ 2010-08-03 5:44 UTC (permalink / raw) To: john stultz Cc: Nick Piggin, Nick Piggin, linux-fsdevel, linux-kernel, linux-mm, Frank Mayhar On Mon, Aug 02, 2010 at 05:27:59PM -0700, John Stultz wrote: > On Fri, 2010-07-30 at 19:12 +1000, Nick Piggin wrote: > > On Fri, Jul 23, 2010 at 05:01:00AM +1000, Nick Piggin wrote: > > > I'm pleased to announce I have a git tree up of my vfs scalability work. > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git > > > http://git.kernel.org/?p=linux/kernel/git/npiggin/linux-npiggin.git > > > > > > Branch vfs-scale-working > > > > > > The really interesting new item is the store-free path walk, (43fe2b) > > > which I've re-introduced. It has had a complete redesign, it has much > > > better performance and scalability in more cases, and is actually sane > > > code now. > > > > Things are progressing well here with fixes and improvements to the > > branch. > > Hey Nick, > Just another minor compile issue with today's vfs-scale-working branch. > > fs/fuse/dir.c:231: error: a??fuse_dentry_revalidate_rcua?? undeclared here > (not in a function) > > >From looking at the vfat and ecryptfs changes in > 582c56f032983e9a8e4b4bd6fac58d18811f7d41 it looks like you intended to > add the following? Thanks John, you're right. I thought I actually linked and ran this, but I must not have had fuse compiled in. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: VFS scalability git tree @ 2010-08-03 5:44 ` Nick Piggin 0 siblings, 0 replies; 76+ messages in thread From: Nick Piggin @ 2010-08-03 5:44 UTC (permalink / raw) To: john stultz Cc: Nick Piggin, Nick Piggin, linux-fsdevel, linux-kernel, linux-mm, Frank Mayhar On Mon, Aug 02, 2010 at 05:27:59PM -0700, John Stultz wrote: > On Fri, 2010-07-30 at 19:12 +1000, Nick Piggin wrote: > > On Fri, Jul 23, 2010 at 05:01:00AM +1000, Nick Piggin wrote: > > > I'm pleased to announce I have a git tree up of my vfs scalability work. > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git > > > http://git.kernel.org/?p=linux/kernel/git/npiggin/linux-npiggin.git > > > > > > Branch vfs-scale-working > > > > > > The really interesting new item is the store-free path walk, (43fe2b) > > > which I've re-introduced. It has had a complete redesign, it has much > > > better performance and scalability in more cases, and is actually sane > > > code now. > > > > Things are progressing well here with fixes and improvements to the > > branch. > > Hey Nick, > Just another minor compile issue with today's vfs-scale-working branch. > > fs/fuse/dir.c:231: error: ‘fuse_dentry_revalidate_rcu’ undeclared here > (not in a function) > > >From looking at the vfat and ecryptfs changes in > 582c56f032983e9a8e4b4bd6fac58d18811f7d41 it looks like you intended to > add the following? Thanks John, you're right. I thought I actually linked and ran this, but I must not have had fuse compiled in. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: VFS scalability git tree 2010-08-03 5:44 ` Nick Piggin (?) (?) @ 2010-09-14 22:26 ` Christoph Hellwig 2010-09-14 23:02 ` Frank Mayhar -1 siblings, 1 reply; 76+ messages in thread From: Christoph Hellwig @ 2010-09-14 22:26 UTC (permalink / raw) To: Nick Piggin; +Cc: linux-fsdevel, linux-kernel Nick, what's the plan for going ahead with the VFS scalability work? We're pretty late in the 2.6.36 cycle now and it would be good to get the next batch prepared and reivew so that it can get some testing in -next. As mentioned before my preference would be the inode lock splitup and related patches - they are relatively simple and we're already seeing workloads where inode_lock really hurts in the writeback code. ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: VFS scalability git tree 2010-09-14 22:26 ` Christoph Hellwig @ 2010-09-14 23:02 ` Frank Mayhar 0 siblings, 0 replies; 76+ messages in thread From: Frank Mayhar @ 2010-09-14 23:02 UTC (permalink / raw) To: Christoph Hellwig; +Cc: Nick Piggin, linux-fsdevel, linux-kernel On Tue, 2010-09-14 at 18:26 -0400, Christoph Hellwig wrote: > Nick, > > what's the plan for going ahead with the VFS scalability work? We're > pretty late in the 2.6.36 cycle now and it would be good to get the next > batch prepared and reivew so that it can get some testing in -next. > > As mentioned before my preference would be the inode lock splitup and > related patches - they are relatively simple and we're already seeing > workloads where inode_lock really hurts in the writeback code. For the record, while I've been quiet here (really busy) I have run a bunch of pretty serious tests against the original set of patches (note: _not_ the latest bits in Nick's tree, I have those queued up but haven't gotten to them yet). So far I haven't seen any instability at all. (I did see one case in which a test that does a _lot_ of network traffic with tons of sockets saw a 20+% performance hit on a system with a relatively moderate number of cores but I haven't had the time to characterize it better and want to test against the newer bits in any event. Sorry to be so vague, I can't really be more specific at this point. Nailing this down is _also_ on my list.) Performance notwithstanding, I'm impressed with the stability of those original patches. I've run VM stress tests against it, FS stress tests, lots of benchmarks and a bunch of other stuff and it's solid, no crashes nor any anomalous behavior. That being the case, I would vote enthusiastically for bringing in the inode_lock splitup as soon as is feasible. -- Frank Mayhar <fmayhar@google.com> Google, Inc. ^ permalink raw reply [flat|nested] 76+ messages in thread
end of thread, other threads:[~2010-09-14 23:02 UTC | newest] Thread overview: 76+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-07-22 19:01 VFS scalability git tree Nick Piggin 2010-07-22 19:01 ` Nick Piggin 2010-07-23 11:13 ` Dave Chinner 2010-07-23 11:13 ` Dave Chinner 2010-07-23 14:04 ` [PATCH 0/2] vfs scalability tree fixes Dave Chinner 2010-07-23 14:04 ` Dave Chinner 2010-07-23 16:09 ` Nick Piggin 2010-07-23 16:09 ` Nick Piggin 2010-07-23 14:04 ` [PATCH 1/2] xfs: fix shrinker build Dave Chinner 2010-07-23 14:04 ` Dave Chinner 2010-07-23 14:04 ` [PATCH 2/2] xfs: shrinker should use a per-filesystem scan count Dave Chinner 2010-07-23 14:04 ` Dave Chinner 2010-07-23 15:51 ` VFS scalability git tree Nick Piggin 2010-07-23 15:51 ` Nick Piggin 2010-07-24 0:21 ` Dave Chinner 2010-07-24 0:21 ` Dave Chinner 2010-07-23 11:17 ` Christoph Hellwig 2010-07-23 11:17 ` Christoph Hellwig 2010-07-23 15:42 ` Nick Piggin 2010-07-23 15:42 ` Nick Piggin 2010-07-23 13:55 ` Dave Chinner 2010-07-23 13:55 ` Dave Chinner 2010-07-23 16:16 ` Nick Piggin 2010-07-23 16:16 ` Nick Piggin 2010-07-27 7:05 ` Nick Piggin 2010-07-27 7:05 ` Nick Piggin 2010-07-27 8:06 ` Nick Piggin 2010-07-27 8:06 ` Nick Piggin 2010-07-27 11:36 ` XFS hang in xlog_grant_log_space (was Re: VFS scalability git tree) Nick Piggin 2010-07-27 13:30 ` Dave Chinner 2010-07-27 14:58 ` XFS hang in xlog_grant_log_space Dave Chinner 2010-07-28 13:17 ` Dave Chinner 2010-07-29 14:05 ` Nick Piggin 2010-07-29 22:56 ` Dave Chinner 2010-07-30 3:59 ` Nick Piggin 2010-07-28 12:57 ` VFS scalability git tree Dave Chinner 2010-07-28 12:57 ` Dave Chinner 2010-07-29 14:03 ` Nick Piggin 2010-07-29 14:03 ` Nick Piggin 2010-07-27 11:09 ` Nick Piggin 2010-07-27 11:09 ` Nick Piggin 2010-07-27 13:18 ` Dave Chinner 2010-07-27 13:18 ` Dave Chinner 2010-07-27 15:09 ` Nick Piggin 2010-07-27 15:09 ` Nick Piggin 2010-07-28 4:59 ` Dave Chinner 2010-07-28 4:59 ` Dave Chinner 2010-07-28 4:59 ` Dave Chinner 2010-07-23 15:35 ` Nick Piggin 2010-07-23 15:35 ` Nick Piggin 2010-07-24 8:43 ` KOSAKI Motohiro 2010-07-24 8:43 ` KOSAKI Motohiro 2010-07-24 8:44 ` [PATCH 1/2] vmscan: shrink_all_slab() use reclaim_state instead the return value of shrink_slab() KOSAKI Motohiro 2010-07-24 8:44 ` KOSAKI Motohiro 2010-07-24 8:44 ` KOSAKI Motohiro 2010-07-24 12:05 ` KOSAKI Motohiro 2010-07-24 12:05 ` KOSAKI Motohiro 2010-07-24 8:46 ` [PATCH 2/2] vmscan: change shrink_slab() return tyep with void KOSAKI Motohiro 2010-07-24 8:46 ` KOSAKI Motohiro 2010-07-24 8:46 ` KOSAKI Motohiro 2010-07-24 10:54 ` VFS scalability git tree KOSAKI Motohiro 2010-07-24 10:54 ` KOSAKI Motohiro 2010-07-26 5:41 ` Nick Piggin 2010-07-26 5:41 ` Nick Piggin 2010-07-28 10:24 ` Nick Piggin 2010-07-28 10:24 ` Nick Piggin 2010-07-30 9:12 ` Nick Piggin 2010-07-30 9:12 ` Nick Piggin 2010-08-03 0:27 ` john stultz 2010-08-03 0:27 ` john stultz 2010-08-03 0:27 ` john stultz 2010-08-03 5:44 ` Nick Piggin 2010-08-03 5:44 ` Nick Piggin 2010-08-03 5:44 ` Nick Piggin 2010-09-14 22:26 ` Christoph Hellwig 2010-09-14 23:02 ` Frank Mayhar
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.
