From: "John Hawkes" <hawkes@sgi.com>
To: "Robert Love" <rml@novell.com>
Cc: "John McCutchan" <ttb@tentacle.dhs.org>,
"John Hawkes" <hawkes@tomahawk.engr.sgi.com>,
<linux-kernel@vger.kernel.org>
Subject: Re: 2.6.10-mm3 scaling problem with inotify
Date: Fri, 14 Jan 2005 10:39:56 -0800 [thread overview]
Message-ID: <002901c4fa68$7266a990$6900a8c0@comcast.net> (raw)
In-Reply-To: 1105726549.6027.268.camel@localhost
From: "Robert Love" <rml@novell.com>
> On Fri, 2005-01-14 at 10:05 -0800, John Hawkes wrote:
>
> > The patch shows a substantial 4x improvement for my specific workload
(@64p),
> > although I can still envision workloads that will stimulate high spinlock
> > contention from spin_lock(&dentry->d_lock). First things first -- let's
get
> > this fix into the -mm tree. Thanks!
>
> Glad it worked!
>
> Does the spin_lock() show up in dnotify's code path? It is getting
> called, unconditionally, there, too.
No, it doesn't show up (with this workload).
Lock contention and cacheline contention can be complex. Contention in one
area can alter the timing of other areas and reduce contention. Anyway, with
your inotify_dentry_parent_queue_event() patch, the PC sampling for my
workload is now (with the lock waits getting rolled up to the callers) for
everything above 0.1% is:
12:38pm Samples: 1887402, Mode: pc, load average: 1832.89, 1722.88, 1264.14
COUNT ( % ) ADDR NAME
843466 (44.7) a000000100147ba0 vma_adjust
521940 (27.7) a0000001001131a0 USER
278285 (14.7) a000000100150d20 anon_vma_unlink
26952 ( 1.4) a000000100150ba0 anon_vma_link
26099 ( 1.4) a00000010013c1e0 clear_page_range
16638 ( 0.9) a0000001007473e0 established_get_next
12378 ( 0.7) a00000010044b200 _mcount
12150 ( 0.6) a000000100039d20 ia64_brk
10237 ( 0.5) a00000010013dba0 zap_pte_range
9886 ( 0.5) a00000010044aba0 copy_page
9311 ( 0.5) a00000010013cfe0 copy_pte_range
8239 ( 0.4) a00000010014bcc0 do_munmap
5014 ( 0.3) a0000001001c1340 update_atime
4743 ( 0.3) a00000010044b300 __copy_user
4462 ( 0.2) a0000001004dc360 inotify_dentry_parent_queue_event
4439 ( 0.2) a000000100115020 find_get_page
3602 ( 0.2) a0000001000b0e40 copy_mm
3581 ( 0.2) a0000001000d3d80 del_timer_sync
2951 ( 0.2) a0000001001720e0 vfs_read
John Hawkes
next prev parent reply other threads:[~2005-01-14 18:40 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-13 23:56 2.6.10-mm3 scaling problem with inotify John Hawkes
2005-01-14 0:49 ` Robert Love
2005-01-14 1:31 ` John McCutchan
2005-01-14 2:29 ` Robert Love
2005-01-14 18:05 ` John Hawkes
2005-01-14 18:15 ` Robert Love
2005-01-14 18:39 ` John Hawkes [this message]
-- strict thread matches above, loose matches on Subject: below --
2005-01-14 0:51 John Hawkes
2005-01-14 2:31 Zou, Nanhai
2005-01-14 2:36 ` John McCutchan
2005-01-14 2:41 ` Robert Love
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='002901c4fa68$7266a990$6900a8c0@comcast.net' \
--to=hawkes@sgi.com \
--cc=hawkes@tomahawk.engr.sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rml@novell.com \
--cc=ttb@tentacle.dhs.org \
/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