From: Andrew Morton <akpm@linux-foundation.org>
To: NeilBrown <neilb@suse.de>
Cc: nfs@lists.sourceforge.net, linux-kernel@vger.kernel.org,
"J. Bruce Fields" <bfields@citi.umich.edu>,
"J. Bruce Fields" <bfields@fieldses.org>
Subject: Re: [PATCH 007 of 8] knfsd: nfsd4: vary maximum delegation limit based on RAM size
Date: Mon, 25 Jun 2007 20:52:44 -0700 [thread overview]
Message-ID: <20070625205244.bbf0976a.akpm@linux-foundation.org> (raw)
In-Reply-To: <1070621043112.1144@suse.de>
On Thu, 21 Jun 2007 14:31:12 +1000 NeilBrown <neilb@suse.de> wrote:
>
> From: "J. Bruce Fields" <bfields@fieldses.org>
>
>
> Our original NFSv4 delegation policy was to give out a read delegation
> on any open when it was possible to.
>
> Since the lifetime of a delegation isn't limited to that of an open, a
> client may quite reasonably hang on to a delegation as long as it has
> the inode cached. This becomes an obvious problem the first time a
> client's inode cache approaches the size of the server's total memory.
>
> Our first quick solution was to add a hard-coded limit. This patch
> makes a mild incremental improvement by varying that limit according to
> the server's total memory size, allowing at most 4 delegations per
> megabyte of RAM.
>
> My quick back-of-the-envelope calculation finds that in the worst case
> (where every delegation is for a different inode), a delegation could
> take about 1.5K, which would make the worst case usage about 6% of
> memory. The new limit works out to be about the same as the old on a
> 1-gig server.
>
> ...
>
> +static void
> +set_max_delegations()
> +{
> + struct sysinfo sys;
> +
> + si_meminfo(&sys);
> + sys.totalram *= sys.mem_unit;
> + sys.totalram >>= (18 - PAGE_SHIFT);
> + max_delegations = (unsigned int) sys.totalram;
> +}
Please put yourself in the position of the reader who happens across this
code and wonders why it is that way.
They could of course go hunt it out of the git repo but I do think it's
quite a bit more reader-friendly to explain the thinking in code comments.
next prev parent reply other threads:[~2007-06-26 3:53 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-21 4:30 [PATCH 000 of 8] knfsd: Assorted nfsv4 server patches NeilBrown
2007-06-21 4:30 ` [PATCH 001 of 8] knfsd: lockd: nfsd4: use same grace period for lockd and nfsd4 NeilBrown
2007-06-21 4:30 ` [PATCH 002 of 8] knfsd: nfsd4: fix NFSv4 filehandle size units confusion NeilBrown
2007-06-21 4:30 ` [PATCH 003 of 8] knfsd: nfsd4: silence a compiler warning in ACL code NeilBrown
2007-06-21 4:30 ` [PATCH 004 of 8] knfsd: nfsd4: fix enc_stateid_sz for nfsd callbacks NeilBrown
2007-06-21 4:30 ` [PATCH 005 of 8] knfsd: nfsd4: fix handling of acl errrors NeilBrown
2007-06-21 4:31 ` [PATCH 006 of 8] knfsd: nfsd: remove unused header interface.h NeilBrown
2007-06-21 4:31 ` [PATCH 007 of 8] knfsd: nfsd4: vary maximum delegation limit based on RAM size NeilBrown
2007-06-21 16:15 ` J. Bruce Fields
2007-06-26 3:52 ` Andrew Morton [this message]
2007-06-28 2:15 ` J. Bruce Fields
2007-06-28 2:36 ` Andrew Morton
2007-06-28 2:57 ` J. Bruce Fields
2007-06-28 3:10 ` Andrew Morton
2007-06-21 4:31 ` [PATCH 008 of 8] knfsd: nfsd4: don't delegate files that have had conflicts NeilBrown
2007-06-21 16:28 ` J. Bruce Fields
2007-06-21 16:33 ` J. Bruce Fields
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=20070625205244.bbf0976a.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=bfields@citi.umich.edu \
--cc=bfields@fieldses.org \
--cc=linux-kernel@vger.kernel.org \
--cc=neilb@suse.de \
--cc=nfs@lists.sourceforge.net \
/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