From: NeilBrown <neilb@suse.de>
To: David Howells <dhowells@redhat.com>
Cc: Milosz Tanski <milosz@adfin.com>,
ceph-devel <ceph-devel@vger.kernel.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"linux-cachefs@redhat.com" <linux-cachefs@redhat.com>
Subject: Re: fscache recursive hang -- similar to loopback NFS issues
Date: Wed, 30 Jul 2014 07:17:35 +1000 [thread overview]
Message-ID: <20140730071735.21ab7ca6@notabene.brown> (raw)
In-Reply-To: <29057.1406650354@warthog.procyon.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1455 bytes --]
On Tue, 29 Jul 2014 17:12:34 +0100 David Howells <dhowells@redhat.com> wrote:
> Milosz Tanski <milosz@adfin.com> wrote:
>
> > That's the same thing exact fix I started testing on Saturday. I found that
> > there already is a wait_event_timeout (even without your recent changes). The
> > thing I'm not quite sure is what timeout it should use?
>
> That's probably something to make an external tuning knob for.
>
> David
Ugg. External tuning knobs should be avoided wherever possible, and always
come with detailed instructions on how to tune them </rant>
In this case I think it very nearly doesn't matter *at all* what value is
used.
If you set it a bit too high, then on the very very rare occasion that it
would currently deadlock, you get a longer-than-necessary wait. So just make
sure that is short enough that by the time the sysadmin notices and starts
looking for the problem, it will be gone.
And if you set it a bit too low, then it will loop around to find another
page to deal with before that one is finished being written out, and so maybe
do a little bit more work than is needed (though it'll be needed eventually).
So the perfect number is somewhere between the typical response time for
storage, and the typical response time for the sys-admin. Anywhere between
100ms and 10sec would do. 1 second is the geo-mean.
(sorry I didn't reply earlier - I missed you email somehow).
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
next prev parent reply other threads:[~2014-07-29 21:17 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-19 20:20 fscache recursive hang -- similar to loopback NFS issues Milosz Tanski
2014-07-19 20:31 ` Milosz Tanski
2014-07-21 6:40 ` NeilBrown
2014-07-21 11:42 ` Milosz Tanski
2014-07-29 16:12 ` David Howells
2014-07-29 21:17 ` NeilBrown [this message]
2014-07-30 1:48 ` Milosz Tanski
2014-07-30 2:19 ` NeilBrown
2014-07-30 16:06 ` Milosz Tanski
2014-08-05 4:12 ` Milosz Tanski
2014-08-05 4:49 ` NeilBrown
2014-08-05 14:32 ` David Howells
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=20140730071735.21ab7ca6@notabene.brown \
--to=neilb@suse.de \
--cc=ceph-devel@vger.kernel.org \
--cc=dhowells@redhat.com \
--cc=linux-cachefs@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=milosz@adfin.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 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).