Received: by 10.223.185.116 with SMTP id b49csp8832583wrg; Fri, 2 Mar 2018 08:41:48 -0800 (PST) X-Google-Smtp-Source: AG47ELtRw8Qd9olw+kuMMVKr7bf6025Gm1GPw36Xtys0JFzfkbVoLwwJk2IlZaoQW+CLCqezmMn+ X-Received: by 2002:a17:902:5e3:: with SMTP id f90-v6mr5776012plf.413.1520008908147; Fri, 02 Mar 2018 08:41:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520008908; cv=none; d=google.com; s=arc-20160816; b=hq7isoa9qHRvY9RgV0ATV1rgmwBY265Uy6U3HYQVKWfZ+0WhYPTmq9P9+dZ7Qp04Am vwhlkpTN1vK3SSEP1RvsChvCsypuohtXXe/moTxXbifNwkYFCaodGerBnYaHaTgFoBfo 4fRfZ0fnt1YKKg7zoWnwMsfGTQc4qux97nq3ghu7sH7R9YUrqCzkwMZ9N+2Ojv0hqR2w PhkpqVhR6Q+2xym+U2KVCtNa9NL/Zwv4FovS/tltpSOOTLK4U3iA50sU1ajRY/aJtnWQ i8f5uLv/QYr9klCNwmI05bGzhcXPEe3q+n12Rve8Bc2SbfzS03aoFQ00bFD3r7TcC91y rOXQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=aLlWC5s5cbQGK1gsJ/bWROGKlYG8KWCvqupPKjR26hY=; b=ki4VnzNE9+Cc6xmrhXdimFeG7Vf1M7yjSb3+GCRjQfzEG9JP6U0FBTSz5gd+1X76fz mkMot9sA6KDcQF1T5TC+NW8wgH3CnFNZEkt+cPp9pV1zmwAY57m7Ys4Dbu9CxcaCehhE Xz/TGVm6OiF+BMqZfLi04aVHhJ4DFFzIWBSmAytnxNEcDJVBW0Kb6xBj3GdGsDPYkH5/ rmgObasaLh1/8pEGGASWK4JiRk61UUbLLop3P4RqXg7pjfe6OedyTBuQX3NCWKdKv7rK uBxLyIy7w2Fe8qo3Cnk/Ukmvs9jrioa7M1JYej0Lb4yEn+q0RF+nmlCZ/bAKa2+bPpEn 4WGA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=KDeqK49a; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 83si4176159pge.817.2018.03.02.08.41.33; Fri, 02 Mar 2018 08:41:48 -0800 (PST) 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; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=KDeqK49a; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936655AbeCBQgN (ORCPT + 99 others); Fri, 2 Mar 2018 11:36:13 -0500 Received: from userp2120.oracle.com ([156.151.31.85]:60622 "EHLO userp2120.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S936306AbeCBQgK (ORCPT ); Fri, 2 Mar 2018 11:36:10 -0500 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w22GVut5055628; Fri, 2 Mar 2018 16:36:06 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=corp-2017-10-26; bh=aLlWC5s5cbQGK1gsJ/bWROGKlYG8KWCvqupPKjR26hY=; b=KDeqK49ae+3bvDgLD0haH48Ad3vPQuZGg/gNCFXuZ4ErtAP/J7ZTRCCh+U0u3XwAttqn tc1+ttMOP1bbvd2UNX379LVYhcROAzqLmdZOdwjkV01D4k13fTijD8JweIH/GHrYkbZL qxra+il9Nhjhi4md/VA2gFS0RRaJ2Q72h+X2d3JASmIfSN0lRwOkNvp4aOazBN0dLsv4 hpZycASkQCv6CD2qnM04mHnuCUM+8Wm8hPRSkMIslDQvGQhgQAGEmZpUdCJ2uLmz+ymS KP62SeEvEZbhEt1vZ+3a+HDqnniVT9Zkzhe+kF79k+x3A5tpxWXdDZ9r7BkmnO7GaAV5 8A== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp2120.oracle.com with ESMTP id 2gf4mhskbw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 02 Mar 2018 16:36:06 +0000 Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w22Ga5bW024923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 2 Mar 2018 16:36:05 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w22Ga4g8030350; Fri, 2 Mar 2018 16:36:05 GMT Received: from localhost (/67.169.218.210) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 02 Mar 2018 08:36:04 -0800 Date: Fri, 2 Mar 2018 08:36:03 -0800 From: "Darrick J. Wong" To: Vratislav Bendel Cc: linux-xfs@vger.kernel.org, Brian Foster , linux-kernel@vger.kernel.org, djwong@kernel.org Subject: Re: [PATCH] xfs: Correctly invert xfs_buftarg LRU isolation logic Message-ID: <20180302163603.GQ19312@magnolia> References: <20180228154951.31714-1-vbendel@redhat.com> <20180301224800.GI12763@magnolia> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180301224800.GI12763@magnolia> User-Agent: Mutt/1.5.24 (2015-08-30) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8820 signatures=668682 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=2 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803020194 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 01, 2018 at 02:48:00PM -0800, Darrick J. Wong wrote: > On Wed, Feb 28, 2018 at 04:49:51PM +0100, Vratislav Bendel wrote: > > The function xfs_buftarg_isolate() used by xfs buffer schrinkers > > to determine whether a buffer should be isolated and disposed > > from LRU list, has inverted logic. > > > > Excerpt from xfs_buftarg_isolate(): > > /* > > * Decrement the b_lru_ref count unless the value is already > > * zero. If the value is already zero, we need to reclaim the > > * buffer, otherwise it gets another trip through the LRU. > > */ > > if (!atomic_add_unless(&bp->b_lru_ref, -1, 0)) { > > spin_unlock(&bp->b_lock); > > return LRU_ROTATE; > > } > > > > However, as per documentation, atomic_add_unless() returns _zero_ > > if the atomic value was originally equal to the specified *unsless* value. > > > > Ultimately causing a xfs_buffer with ->b_lru_ref == 0, to take another > > trip around LRU, while isolating buffers with non-zero b_lru_ref. > > > > Signed-off-by: Vratislav Bendel > > CC: Brian Foster > > Looks ok, will test... > Reviewed-by: Darrick J. Wong This tests ok, but please address Brian and Luis' comments before I put this in the upstream tream. --D > --D > > > --- > > fs/xfs/xfs_buf.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/fs/xfs/xfs_buf.c b/fs/xfs/xfs_buf.c > > index d1da2ee9e6db..ac669a10c62f 100644 > > --- a/fs/xfs/xfs_buf.c > > +++ b/fs/xfs/xfs_buf.c > > @@ -1708,7 +1708,7 @@ xfs_buftarg_isolate( > > * zero. If the value is already zero, we need to reclaim the > > * buffer, otherwise it gets another trip through the LRU. > > */ > > - if (!atomic_add_unless(&bp->b_lru_ref, -1, 0)) { > > + if (atomic_add_unless(&bp->b_lru_ref, -1, 0)) { > > spin_unlock(&bp->b_lock); > > return LRU_ROTATE; > > } > > -- > > 2.14.3 > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-xfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html