linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Trond Myklebust <Trond.Myklebust@netapp.com>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: linux-nfs@vger.kernel.org
Subject: Re: [PATCH 08/15] SUNRPC: Ensure rpcauth_prune_expired() respects the nr_to_scan parameter
Date: Fri, 14 May 2010 13:13:20 -0400	[thread overview]
Message-ID: <1273857200.4732.2.camel@localhost.localdomain> (raw)
In-Reply-To: <4BED7BAD.20509@oracle.com>

On Fri, 2010-05-14 at 12:34 -0400, Chuck Lever wrote: 
> On 05/13/10 05:08 PM, Trond Myklebust wrote:
> > Signed-off-by: Trond Myklebust<Trond.Myklebust@netapp.com>
> > ---
> >   net/sunrpc/auth.c |    5 ++---
> >   1 files changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/net/sunrpc/auth.c b/net/sunrpc/auth.c
> > index 2213dc5..5fb02ac 100644
> > --- a/net/sunrpc/auth.c
> > +++ b/net/sunrpc/auth.c
> > @@ -236,6 +236,8 @@ rpcauth_prune_expired(struct list_head *free, int nr_to_scan)
> >
> >   	list_for_each_entry_safe(cred, next,&cred_unused, cr_lru) {
> >
> > +		if (nr_to_scan-- == 0)
> > +			break;
> >   		/*
> >   		 * Enforce a 60 second garbage collection moratorium
> >   		 * Note that the cred_unused list must be time-ordered.
> > @@ -255,11 +257,8 @@ rpcauth_prune_expired(struct list_head *free, int nr_to_scan)
> >   			get_rpccred(cred);
> >   			list_add_tail(&cred->cr_lru, free);
> >   			rpcauth_unhash_cred_locked(cred);
> > -			nr_to_scan--;
> >   		}
> >   		spin_unlock(cache_lock);
> > -		if (nr_to_scan == 0)
> > -			break;
> >   	}
> >   	return (number_cred_unused / 100) * sysctl_vfs_cache_pressure;
> >   }
> 
> It looks to me like the mm calls our cache shrinker with nr_to_scan set 
> to zero when it just wants this return value, and nothing more.  But the 
> logic here seems to assume that nr_to_scan == 0 means shrink as much as 
> you can.  Am I reading this correctly?

Look more carefully: the comparison contains a post-decrement operation,
so if the nr_to_scan == 0, then we immediately exit the loop (after
decrementing nr_to_scan, but who cares about that)...

Cheers
  Trond

  reply	other threads:[~2010-05-14 17:13 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-13 21:08 [PATCH 01/15] SUNRPC: Fix xs_setup_bc_tcp() Trond Myklebust
2010-05-13 21:08 ` [PATCH 02/15] NFSv4: Don't use GFP_KERNEL allocations in state recovery Trond Myklebust
2010-05-13 21:08   ` [PATCH 03/15] NFS: Don't use GFP_KERNEL in rpcsec_gss downcalls Trond Myklebust
2010-05-13 21:08     ` [PATCH 04/15] NFS: Clean up nfs_create_request() Trond Myklebust
2010-05-13 21:08       ` [PATCH 05/15] NFS: Read requests can use GFP_KERNEL Trond Myklebust
2010-05-13 21:08         ` [PATCH 06/15] SUNRPC: Dont run rpcauth_cache_shrinker() when gfp_mask is GFP_NOFS Trond Myklebust
2010-05-13 21:08           ` [PATCH 07/15] SUNRPC: Ensure memory shrinker doesn't waste time in rpcauth_prune_expired() Trond Myklebust
2010-05-13 21:08             ` [PATCH 08/15] SUNRPC: Ensure rpcauth_prune_expired() respects the nr_to_scan parameter Trond Myklebust
2010-05-13 21:08               ` [PATCH 09/15] NFS: Don't run nfs_access_cache_shrinker() when the mask is GFP_NOFS Trond Myklebust
2010-05-13 21:08                 ` [PATCH 10/15] NFS: Clean up nfs_access_zap_cache() Trond Myklebust
2010-05-13 21:08                   ` [PATCH 11/15] NFS: Don't call iput() in nfs_access_cache_shrinker Trond Myklebust
2010-05-13 21:08                     ` [PATCH 12/15] SUNRPC: Move the task->tk_bytes_sent and tk_rtt to struct rpc_rqst Trond Myklebust
2010-05-13 21:08                       ` [PATCH 13/15] SUNRPC: Remove the 'tk_magic' debugging field Trond Myklebust
2010-05-13 21:08                         ` [PATCH 14/15] SUNRPC: Reorder the struct rpc_task fields Trond Myklebust
2010-05-13 21:08                           ` [PATCH 15/15] SUNRPC: Don't spam gssd with upcall requests when the kerberos key expired Trond Myklebust
2010-05-14 16:34               ` [PATCH 08/15] SUNRPC: Ensure rpcauth_prune_expired() respects the nr_to_scan parameter Chuck Lever
2010-05-14 17:13                 ` Trond Myklebust [this message]
     [not found]                   ` <1273857200.4732.2.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2010-05-14 17:32                     ` Chuck Lever
2010-05-14 18:07                       ` Trond Myklebust
     [not found]                         ` <1273860432.4732.30.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2010-05-14 18:37                           ` Trond Myklebust
     [not found]                             ` <1273862242.4732.39.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2010-05-14 19:18                               ` Chuck Lever

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=1273857200.4732.2.camel@localhost.localdomain \
    --to=trond.myklebust@netapp.com \
    --cc=chuck.lever@oracle.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 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).