From: "Martin J. Bligh" <mbligh@mbligh.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: Christoph Hellwig <hch@infradead.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Andrew Morton <akpm@osdl.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/7] breaking the global file_list_lock
Date: Sun, 28 Jan 2007 08:52:25 -0800 [thread overview]
Message-ID: <45BCD4C9.2030302@mbligh.org> (raw)
In-Reply-To: <20070128152404.GB9196@elte.hu>
Ingo Molnar wrote:
> * Christoph Hellwig <hch@infradead.org> wrote:
>
>> On Sun, Jan 28, 2007 at 12:51:18PM +0100, Peter Zijlstra wrote:
>>> This patch-set breaks up the global file_list_lock which was found
>>> to be a severe contention point under basically any filesystem
>>> intensive workload.
>> Benchmarks, please. Where exactly do you see contention for this?
>
> it's the most contended spinlock we have during a parallel kernel
> compile on an 8-way system. But it's pretty common-sense as well,
> without doing any measurements, it's basically the only global lock left
> in just about every VFS workload that doesnt involve massive amount of
> dentries created/removed (which is still dominated by the dcache_lock).
>
>> filesystem intensive workload apparently means namespace operation
>> heavy workload, right? The biggest bottleneck I've seen with those is
>> dcache lock.
>
> the dcache lock is not a problem during kernel compiles. (its
> rcu-ification works nicely in that workload)
Mmm. not wholly convinced that's true. Whilst i don't have lockmeter
stats to hand, the heavy time in __d_lookup seems to indicate we may
still have a problem to me. I guess we could move the spinlocks out
of line again to test this fairly easily (or get lockmeter upstream).
114076 total 0.0545
57766 default_idle 916.9206
11869 prep_new_page 49.4542
3830 find_trylock_page 67.1930
2637 zap_pte_range 3.9125
2486 strnlen_user 54.0435
2018 do_page_fault 1.1941
1940 do_wp_page 1.6973
1869 __d_lookup 7.7231
1331 page_remove_rmap 5.2196
1287 do_no_page 1.6108
1272 buffered_rmqueue 4.6423
1160 __copy_to_user_ll 14.6835
1027 _atomic_dec_and_lock 11.1630
655 release_pages 1.9670
644 do_path_lookup 1.6304
630 schedule 0.4046
617 kunmap_atomic 7.7125
573 __handle_mm_fault 0.7365
548 free_hot_page 78.2857
500 __copy_user_intel 3.3784
483 copy_pte_range 0.5941
482 page_address 2.9571
478 file_move 9.1923
441 do_anonymous_page 0.7424
429 filemap_nopage 0.4450
401 anon_vma_unlink 4.8902
next prev parent reply other threads:[~2007-01-28 16:52 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-28 11:51 [PATCH 0/7] breaking the global file_list_lock Peter Zijlstra
2007-01-28 11:51 ` [PATCH 1/7] lockdep: lock_set_subclass - reset a held locks subclass Peter Zijlstra
2007-01-28 11:51 ` [PATCH 3/7] barrier: a scalable synchonisation barrier Peter Zijlstra
2007-01-28 14:39 ` Christoph Hellwig
2007-01-28 15:24 ` Ingo Molnar
2007-01-28 15:34 ` Christoph Hellwig
2007-01-31 19:12 ` Paul E. McKenney
2007-01-31 21:13 ` Oleg Nesterov
2007-01-31 21:30 ` Oleg Nesterov
2007-01-31 21:48 ` Peter Zijlstra
2007-01-31 23:32 ` Paul E. McKenney
2007-02-01 0:03 ` Peter Zijlstra
2007-02-01 0:48 ` Paul E. McKenney
2007-02-01 16:00 ` Oleg Nesterov
2007-02-01 21:38 ` Paul E. McKenney
2007-02-02 11:56 ` Oleg Nesterov
2007-02-02 12:01 ` Peter Zijlstra
2007-02-02 17:13 ` Paul E. McKenney
2007-02-03 16:38 ` Oleg Nesterov
2007-02-04 0:23 ` Paul E. McKenney
2007-02-04 3:24 ` Alan Stern
2007-02-04 5:46 ` Paul E. McKenney
2007-01-28 11:51 ` [PATCH 4/7] fs: break the file_list_lock for sb->s_files Peter Zijlstra
2007-01-28 14:43 ` Christoph Hellwig
2007-01-28 15:21 ` Ingo Molnar
2007-01-28 15:30 ` Christoph Hellwig
2007-01-28 15:32 ` Peter Zijlstra
2007-01-28 15:36 ` Christoph Hellwig
2007-01-28 15:44 ` Ingo Molnar
2007-01-28 16:25 ` Bill Huey
2007-01-28 11:51 ` [PATCH 5/7] fs: restore previous sb->s_files iteration semantics Peter Zijlstra
2007-01-28 11:51 ` [PATCH 6/7] schedule_on_each_cpu_wq() Peter Zijlstra
2007-01-28 11:51 ` [PATCH 7/7] fs: fixup filevec_add_drain_all Peter Zijlstra
2007-01-28 12:16 ` [PATCH 8/7] fs: free_write_pipe() fix Peter Zijlstra
2007-01-28 14:43 ` [PATCH 0/7] breaking the global file_list_lock Christoph Hellwig
2007-01-28 15:11 ` Christoph Hellwig
2007-01-28 15:29 ` Peter Zijlstra
2007-01-28 15:33 ` Christoph Hellwig
2007-01-29 13:32 ` Stephen Smalley
2007-01-29 18:02 ` Christoph Hellwig
2007-01-28 15:24 ` Ingo Molnar
2007-01-28 16:52 ` Martin J. Bligh [this message]
2007-01-28 17:04 ` lockmeter Christoph Hellwig
2007-01-28 17:38 ` lockmeter Martin J. Bligh
2007-01-28 18:01 ` lockmeter Bill Huey
2007-01-28 19:26 ` lockmeter Ingo Molnar
2007-01-28 21:17 ` lockmeter Ingo Molnar
2007-01-29 5:27 ` lockmeter Bill Huey
2007-01-29 10:26 ` lockmeter Bill Huey
2007-01-29 1:08 ` lockmeter Arjan van de Ven
2007-01-29 1:12 ` lockmeter Martin J. Bligh
2007-01-28 18:41 ` [PATCH 0/7] breaking the global file_list_lock Ingo Molnar
2007-01-28 20:38 ` Christoph Hellwig
2007-01-28 21:05 ` Ingo Molnar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=45BCD4C9.2030302@mbligh.org \
--to=mbligh@mbligh.org \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@osdl.org \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).