On Fri, 2013-03-15 at 16:16 +0000, Chris Boot wrote:
> On 05/03/13 09:36, Chris Boot wrote:
> > On 03/03/13 01:56, Ben Hutchings wrote:
> >> Control: tag -1 moreinfo fixed-upstream
> >>
> >> On Thu, 2013-02-28 at 15:28 +0000, Chris Boot wrote:
> >>> We are also seeing this on an NFS server hosing home directories for a
> >>> fairly large deployment of Debian desktop systems. The symptoms and perf
> >>> top agree perfectly with what the reporter is experiencing.
> >>>
> >>> Please consider backporting said patch to the 3.2 kernel for
> >>> wheezy/squeeze-backports.
> >> Please test the attached backport as explained here:
> >> http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official
> > Hi Ben,
> >
> > I have been testing a 3.2 kernel with both the patch you backported as
> > well as 64a284d07c7d84299a90826950079a8ef11e8204 from upstream ("nfsd4:
> > maintain one seqid stream per (lockowner, file)"). These patches
> > together appear to have resolved the issues our client has been seeing,
> > though this is not running in a production environment just yet.
> >
> > I think the other patch (64a284d07c7d84299a90826950079a8ef11e8204) is
> > also quite important in resolving this problem, as it reduces the number
> > of entries in the lockowner hash table. Would this be a patch you would
> > entertain to backport as well?
>
> Hi Ben,
>
> Did you have any further thoughts about the other patch I mentioned
> above? I still don't have this running in a production environment, but
> the testing I have performed looks good with both patches applied.
That's good, but I wonder whether this might also needed:
commit 009673b439cf74d70a486fca0177e274febd81a7
Author: J. Bruce Fields <bfields@redhat.com>
Date: Mon Nov 7 17:40:10 2011 -0500
nfsd4: add a separate (lockowner, inode) lookup
Address the possible performance regression mentioned in "nfsd4: hash
lockowners to simplify RELEASE_LOCKOWNER" by providing a separate
(lockowner, inode) hash.
Really, I doubt this matters much, but I think it's likely we'll change
these data structures here and I'd rather that the need for (owner,
inode) lookups be well-documented.
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
(That might also depend on:
commit 16bfdaafa2c66d8cc81422a97a105a849ca65b3e
Author: J. Bruce Fields <bfields@redhat.com>
Date: Mon Nov 7 17:23:30 2011 -0500
nfsd4: share open and lock owner hash tables
Now that they're used in the same way, it's a little simpler to put open
and lock owners in the same hash table, and I can't see a reason not to.
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
though I think they're independent.)
Ben.
--
Ben Hutchings
When you say `I wrote a program that crashed Windows', people just stare ...
and say `Hey, I got those with the system, *for free*'. - Linus Torvalds
Attachment:
signature.asc
Description: This is a digitally signed message part