Received: by 10.192.165.148 with SMTP id m20csp3903471imm; Mon, 30 Apr 2018 08:18:13 -0700 (PDT) X-Google-Smtp-Source: AB8JxZr3a+8hfT+YxhpSaa6pgyYh9cREDJJDita3mVt4e9lv/h8XxJ5S7bPohIPPKtbNWcgiqd/D X-Received: by 2002:a63:7052:: with SMTP id a18-v6mr10339733pgn.148.1525101493372; Mon, 30 Apr 2018 08:18:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525101493; cv=none; d=google.com; s=arc-20160816; b=0hIgeFVSSpfumSJCxpq/zmaeJuWBrpP8LjcyOFSRC+VOGrSXil/waRwYoFDysDg1w0 AWs07KPhRrbY9AJbxs/k0ECxpjmgejw+Cwsg9It1i7mky3eTb6tiEYAKlFlnYTiTkjzu IWvnQhe1jkRF6auIhldyaFhKyrYvYiPgL9C1Hx9ulJwMVCVLgI3G5F7sm7T3bRR0aMnR ePcpG9WUIdAdyYs6U83uxQtZZwzq2ISLu09SofjD2jJnqQ7j38RRq8zCLVlIyAvl09q3 VlAPibl5Yc6lIKbRI7K3gZXsC8fK4viNA7ojHYwZGjX6aWTgderxj6U4DUPw2SAkJ5p/ a/SQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dmarc-filter:arc-authentication-results; bh=5+l1s/BseTlHhNfpHJFByFhyzvB5b4sWljx+iHiBD6M=; b=tYwisos3bTGJZWvxZTJjimFKDKf8fSxClIj7waTEJ0+SOsAcIYPB1SnBig0Bw1Xjs/ DxGkJMrd/qiuwqMValpTcTjOhnlC2Eo9xzd3eYil0I70S308Qn4plXUJABrHqbz2lYtl cqqmslJO25KCGKs8lbBwdd64ZCWsTsFatPQzS7jpZF0q9avDPsB6a8CkIBtsLzPRh/W4 hLfwlRprmrMV2cvwNF+/pxWCAbzrlk7S3pwRTv7ATXAzRx3viVsSWX9oGEjV2c3Nmo/Q FALTckx8aDAeuvnjVBJXHGdJpOl0r11iMe3xekuM7Dkq4q1LrU7IaJL8BNeEyzHxJXym F0dg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 135si7610242pfc.21.2018.04.30.08.17.58; Mon, 30 Apr 2018 08:18:13 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754138AbeD3PRr (ORCPT + 99 others); Mon, 30 Apr 2018 11:17:47 -0400 Received: from mail.kernel.org ([198.145.29.99]:37498 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751938AbeD3PRo (ORCPT ); Mon, 30 Apr 2018 11:17:44 -0400 Received: from gandalf.local.home (cpe-66-24-56-78.stny.res.rr.com [66.24.56.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id D8C7922C94; Mon, 30 Apr 2018 15:17:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D8C7922C94 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=goodmis.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=rostedt@goodmis.org Date: Mon, 30 Apr 2018 11:17:41 -0400 From: Steven Rostedt To: NeilBrown Cc: "Paul E. McKenney" , Trond Myklebust , Mathieu Desnoyers , Anna Schumaker , linux-nfs@vger.kernel.org, Lai Jiangshan , Josh Triplett , linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/4] NFS: slight optimization for walking list for delegations Message-ID: <20180430111741.561df374@gandalf.local.home> In-Reply-To: <152506269054.7246.3941740801391514623.stgit@noble> References: <152506256513.7246.13171564155614823841.stgit@noble> <152506269054.7246.3941740801391514623.stgit@noble> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 30 Apr 2018 14:31:30 +1000 NeilBrown wrote: > There are 3 places where we walk the list of delegations > for an nfs_client. > In each case there are two nested loops, one for nfs_servers > and one for nfs_delegations. > > When we find an interesting delegation we try to get an active > reference to the server. If that fails, it is pointless to > continue to look at the other delegation for the server as > we will never be able to get an active reference. > So instead of continuing in the inner loop, break out > and continue in the outer loop. > --- > fs/nfs/delegation.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/fs/nfs/delegation.c b/fs/nfs/delegation.c > index 1819d0d0ba4b..af32365894c8 100644 > --- a/fs/nfs/delegation.c > +++ b/fs/nfs/delegation.c > @@ -495,7 +495,7 @@ int nfs_client_return_marked_delegations(struct nfs_client *clp) > if (!nfs_delegation_need_return(delegation)) > continue; > if (!nfs_sb_active(server->super)) > - continue; > + break; For documentation purposes, what I usually do when using a break inside a inner loop to continue the outer loop, I add a comment: break; /* continue outer loop */ Such that in the future, people will know exactly what you mean and don't think it's a bug (thinking it breaks out of all loops). -- Steve > inode = nfs_delegation_grab_inode(delegation); > if (inode == NULL) { > rcu_read_unlock(); > @@ -887,7 +887,7 @@ void nfs_delegation_reap_unclaimed(struct nfs_client *clp) > &delegation->flags) == 0) > continue; > if (!nfs_sb_active(server->super)) > - continue; > + break; > inode = nfs_delegation_grab_inode(delegation); > if (inode == NULL) { > rcu_read_unlock(); > @@ -995,7 +995,7 @@ void nfs_reap_expired_delegations(struct nfs_client *clp) > &delegation->flags) == 0) > continue; > if (!nfs_sb_active(server->super)) > - continue; > + break; > inode = nfs_delegation_grab_inode(delegation); > if (inode == NULL) { > rcu_read_unlock(); >