From: NeilBrown <neilb@suse.de>
To: Bodo Stroesser <bstroesser@ts.fujitsu.com>
Cc: bfields@fieldses.org, linux-nfs@vger.kernel.org
Subject: Re: sunrpc/cache.c: races while updating cache entries
Date: Thu, 13 Jun 2013 11:54:56 +1000 [thread overview]
Message-ID: <20130613115456.02e28f94@notabene.brown> (raw)
In-Reply-To: <61eb00$3oamkh@dgate20u.abg.fsc.net>
[-- Attachment #1: Type: text/plain, Size: 2393 bytes --]
On 03 Jun 2013 16:27:06 +0200 Bodo Stroesser <bstroesser@ts.fujitsu.com>
wrote:
> On Fri, Apr 19, 2013 at 06:56:00PM +0200, Bodo Stroesser wrote:
> >
> > We started the test of the -SP2 (and mainline) series on Tue, 9th, but had no
> > success.
> > We did _not_ find a problem with the patches, but under -SP2 our test scenario
> > has less than 40% of the throughput we saw under -SP1. With that low
> > performance, we had a 4 day run without any dropped RPC request. But we don't
> > know the error rate without the patches under these conditions. So we can't
> > give an o.k. for the patches yet.
> >
> > Currently we try to find the reason for the different behavior of SP1 and SP2
> >
>
> Hi,
>
> sorry for the delay. Meanwhile we found the reason for the small throughput
> with -SP2. The problem resulted from a change in our own software.
>
> Thus I could fix this and started a test on last Tuesday. I stopped the test
> today after 6 days without any lost RPC. Without the patches I saw the first
> dropped RPC after 3 hours. Thus, I think the patches for -SP2 are fine.
>
> @Neil: would patch 0006 of the -SP1 patchset be a good additional change for
> mainline?
>
> Bodo
Thanks for all the testing.
Bruce: where are you at with these? Are you holding one to some that I sent
previously, or should I resend them all?
Bodo: no, I don't think that patch is appropriate for mainline. It causes
sunrpc_cache_pipe_upcall to abort if ->expiry_time is zero. There is
certainly no point in doing an upcall in that case, but the code in mainline
is quite different to the code in -SP1 against which that patch made sense.
For mainline an equivalent optimisation which probably makes the interesting
case more obvious would be:
diff --git a/net/sunrpc/cache.c b/net/sunrpc/cache.c
index d01eb07..291cc47 100644
--- a/net/sunrpc/cache.c
+++ b/net/sunrpc/cache.c
@@ -262,7 +262,8 @@ int cache_check(struct cache_detail *detail,
if (rqstp == NULL) {
if (rv == -EAGAIN)
rv = -ENOENT;
- } else if (rv == -EAGAIN || age > refresh_age/2) {
+ } else if (rv == -EAGAIN ||
+ (refresh_age > 0 && age > refresh_age/2)) {
dprintk("RPC: Want update, refage=%ld, age=%ld\n",
refresh_age, age);
if (!test_and_set_bit(CACHE_PENDING, &h->flags)) {
i.e. trap that case in cache_check.
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
next parent reply other threads:[~2013-06-13 1:55 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <61eb00$3oamkh@dgate20u.abg.fsc.net>
2013-06-13 1:54 ` NeilBrown [this message]
2013-06-13 2:04 ` sunrpc/cache.c: races while updating cache entries J. Bruce Fields
2013-06-03 14:27 Bodo Stroesser
-- strict thread matches above, loose matches on Subject: below --
2013-04-19 16:55 Bodo Stroesser
2013-05-10 7:51 ` Namjae Jeon
2013-05-13 4:08 ` Namjae Jeon
[not found] <d6437a$47jkcm@dgate10u.abg.fsc.net>
2013-04-05 21:08 ` J. Bruce Fields
2013-04-05 15:33 Bodo Stroesser
[not found] <61eb00$3itd78@dgate20u.abg.fsc.net>
2013-04-05 12:40 ` J. Bruce Fields
2013-04-04 17:59 Bodo Stroesser
[not found] <61eb00$3hon1j@dgate20u.abg.fsc.net>
2013-04-03 18:36 ` J. Bruce Fields
2013-03-21 16:41 Bodo Stroesser
[not found] <61eb00$3hl8ah@dgate20u.abg.fsc.net>
2013-03-20 23:33 ` NeilBrown
2013-03-20 18:45 Bodo Stroesser
[not found] <d6437a$45t6bs@dgate10u.abg.fsc.net>
2013-03-20 4:39 ` NeilBrown
2013-03-19 19:58 Bodo Stroesser
[not found] <d6437a$45efvo@dgate10u.abg.fsc.net>
2013-03-19 3:23 ` NeilBrown
2013-03-15 20:35 Bodo Stroesser
2013-03-14 17:31 Bodo Stroesser
2013-03-13 16:47 Bodo Stroesser
[not found] <61eb00$3gpm51@dgate20u.abg.fsc.net>
2013-03-13 5:55 ` NeilBrown
2013-03-11 16:13 Bodo Stroesser
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=20130613115456.02e28f94@notabene.brown \
--to=neilb@suse.de \
--cc=bfields@fieldses.org \
--cc=bstroesser@ts.fujitsu.com \
--cc=linux-nfs@vger.kernel.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 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.