From: Ian Kent <raven@themaw.net>
To: NeilBrown <neilb@suse.de>
Cc: autofs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/5] RCU-walk support for autofs
Date: Wed, 20 Aug 2014 17:52:47 +0800 [thread overview]
Message-ID: <1408528367.11028.44.camel@perseus.themaw.net> (raw)
In-Reply-To: <1408506167.11028.32.camel@perseus.themaw.net>
On Wed, 2014-08-20 at 11:42 +0800, Ian Kent wrote:
> Great minds think alike.
> I have basically the exact same patch and I'm testing now.
> It probably should be folded into "autofs4: avoid taking fs_lock during
> rcu-walk".
>
> It takes ages though, the test has two configurations to test and each
> one takes about 70 minutes.
>
> fyi, my criteria for the test is if it runs through to completion once
> then that's essentially a pass. If not then there is a race that needs
> to be fixed before merge. If it fails on runs two or three then there's
> a hard to find race that needs attention but is not serious enough to
> block merging. I usually stop after three runs but if fails are seen
> later then, they too need to be resolved in the fullness of time.
>
> The reason for this is that in heavy use sites we rarely see more than
> about three processes concurrently accessing mount points and the test
> run uses 10 client instances (currently on a 6 CPU machine) that all
> access the mount tree at the same time so that should be somewhat more
> pressure than is seen under heavy use.
>
> And indeed this rule of has proven reliable so far.
I've run my test three times now.
The first time I had debug logging enabled. I disabled it for the second
and third runs as that sometimes makes a difference.
All three runs went through fine.
The only thing I noticed was that the test took a little longer (two and
a half to three minutes longer, of 70) to complete than without the
patch series but I've seen that sort of variation in kernels at
different times in the past.
So I think the series is fine and should be merged.
Please feel free to add any of my acked, reviewed and tested by to them.
Ian
prev parent reply other threads:[~2014-08-20 9:52 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-18 6:33 [PATCH 0/5] RCU-walk support for autofs NeilBrown
2014-08-18 6:33 ` [PATCH 1/5] autofs4: allow RCU-walk to walk through autofs4 NeilBrown
2014-08-18 6:33 ` [PATCH 4/5] autofs4: d_manage() should return -EISDIR when appropriate in rcu-walk mode NeilBrown
2014-08-18 6:33 ` [PATCH 2/5] autofs4: factor should_expire() out of autofs4_expire_indirect NeilBrown
2014-08-18 6:33 ` [PATCH 5/5] autofs: the documentation I wanted to read NeilBrown
2014-08-18 10:13 ` Ian Kent
2014-08-19 7:00 ` NeilBrown
2014-08-18 6:33 ` [PATCH 3/5] autofs4: avoid taking fs_lock during rcu-walk NeilBrown
2014-08-18 8:25 ` [PATCH 0/5] RCU-walk support for autofs Ian Kent
2014-08-19 10:02 ` Ian Kent
2014-08-19 11:16 ` NeilBrown
2014-08-19 12:30 ` Ian Kent
2014-08-19 12:36 ` Ian Kent
2014-08-20 3:13 ` NeilBrown
2014-08-20 3:42 ` Ian Kent
2014-08-20 3:50 ` Ian Kent
2014-08-20 9:52 ` Ian Kent [this message]
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=1408528367.11028.44.camel@perseus.themaw.net \
--to=raven@themaw.net \
--cc=autofs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=neilb@suse.de \
/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.