From: Nick Piggin <nickpiggin@yahoo.com.au>
To: john@johnmccutchan.com
Cc: Andrew Morton <akpm@osdl.org>,
holt@sgi.com, linux-kernel@vger.kernel.org, rml@novell.com,
arnd@arndb.de, hch@lst.de, Dipankar Sarma <dipankar@in.ibm.com>
Subject: Re: udevd is killing file write performance.
Date: Mon, 27 Feb 2006 21:11:05 +1100 [thread overview]
Message-ID: <4402D039.1050307@yahoo.com.au> (raw)
In-Reply-To: <1140972918.15634.1.camel@localhost.localdomain>
John McCutchan wrote:
> On Fri, 2006-24-02 at 18:07 +1100, Nick Piggin wrote:
>>I saw this problem when testing my lockless pagecache a while back.
>>
>>Attached is a first implementation of what was my idea then of how
>>to solve it... note it is pretty rough and I never got around to doing
>>much testing of it.
>>
>>Basically: moves work out of inotify event time and to inotify attach
>>/detach time while staying out of the core VFS.
>
>
>
> This looks really good. There might be some corner cases but it looks
> like it will solve this problem nicely.
>
Thanks. You should see I sent a new version which fixes several bugs
and cleans up the code a bit.
There might be some areas of potential problems:
- creating and deleting watches on directories with many entries will
take a long time. Is anyone likely to be creating and destroying
these things at a very high frequency? Probably nobody cares except
it might twist some real-time knickers.
- concurrent operations in the same watched directory will incur the
same scalability penalty. I think this is basically a non-issue since
the sheer number of events coming out will likely be a bigger problem.
Doctor, it hurts when I do this.
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
next prev parent reply other threads:[~2006-02-27 10:11 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-22 13:42 udevd is killing file write performance Robin Holt
2006-02-22 13:55 ` Andrew Morton
2006-02-22 16:48 ` John McCutchan
2006-02-22 17:50 ` Robin Holt
2006-02-22 20:05 ` Andrew Morton
2006-02-22 21:50 ` Jeff V. Merkey
2006-02-23 12:56 ` Robin Holt
2006-02-23 13:42 ` David Chinner
2006-02-22 22:52 ` John McCutchan
2006-02-22 23:12 ` Andrew Morton
2006-02-22 23:41 ` John McCutchan
2006-02-24 0:14 ` Andrew Morton
2006-02-24 0:14 ` Andrew Morton
2006-02-24 5:47 ` John McCutchan
2006-02-24 6:00 ` Andrew Morton
2006-02-24 7:07 ` Nick Piggin
2006-02-24 7:16 ` Andrew Morton
2006-02-24 7:19 ` Nick Piggin
2006-02-26 16:58 ` John McCutchan
2006-02-24 18:56 ` Robin Holt
2006-02-25 2:44 ` Nick Piggin
2006-02-25 15:53 ` [patch] inotify: lock avoidance with parent watch status in dentry Nick Piggin
2006-02-28 0:48 ` Andrew Morton
2006-02-26 16:55 ` udevd is killing file write performance John McCutchan
2006-02-27 10:11 ` Nick Piggin [this message]
2006-02-27 20:17 ` John McCutchan
2006-02-23 20:38 ` Benjamin LaHaise
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=4402D039.1050307@yahoo.com.au \
--to=nickpiggin@yahoo.com.au \
--cc=akpm@osdl.org \
--cc=arnd@arndb.de \
--cc=dipankar@in.ibm.com \
--cc=hch@lst.de \
--cc=holt@sgi.com \
--cc=john@johnmccutchan.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rml@novell.com \
/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 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.