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 <bfie...@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 <bfie...@redhat.com>
(That might also depend on:
commit 16bfdaafa2c66d8cc81422a97a105a849ca65b3e
Author: J. Bruce Fields <bfie...@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 <bfie...@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
signature.asc
Description: This is a digitally signed message part
