From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B7FF2ECE58C for ; Fri, 11 Oct 2019 15:30:02 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8003E21A4A for ; Fri, 11 Oct 2019 15:30:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8003E21A4A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 236208E0005; Fri, 11 Oct 2019 11:30:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1E7188E0001; Fri, 11 Oct 2019 11:30:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0FCDF8E0005; Fri, 11 Oct 2019 11:30:02 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0171.hostedemail.com [216.40.44.171]) by kanga.kvack.org (Postfix) with ESMTP id E0EC08E0001 for ; Fri, 11 Oct 2019 11:30:01 -0400 (EDT) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with SMTP id 614CE6118 for ; Fri, 11 Oct 2019 15:30:01 +0000 (UTC) X-FDA: 76031889402.06.limit60_748c5333e5955 X-HE-Tag: limit60_748c5333e5955 X-Filterd-Recvd-Size: 3895 Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by imf36.hostedemail.com (Postfix) with ESMTP for ; Fri, 11 Oct 2019 15:30:00 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D10683065450; Fri, 11 Oct 2019 15:29:59 +0000 (UTC) Received: from bfoster (dhcp-41-2.bos.redhat.com [10.18.41.2]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 53E745E1C5; Fri, 11 Oct 2019 15:29:59 +0000 (UTC) Date: Fri, 11 Oct 2019 11:29:57 -0400 From: Brian Foster To: Dave Chinner Cc: linux-xfs@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH 17/26] xfs: don't block kswapd in inode reclaim Message-ID: <20191011152957.GI61257@bfoster> References: <20191009032124.10541-1-david@fromorbit.com> <20191009032124.10541-18-david@fromorbit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191009032124.10541-18-david@fromorbit.com> User-Agent: Mutt/1.12.1 (2019-06-15) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.40]); Fri, 11 Oct 2019 15:29:59 +0000 (UTC) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Oct 09, 2019 at 02:21:15PM +1100, Dave Chinner wrote: > From: Dave Chinner > > We have a number of reasons for blocking kswapd in XFS inode > reclaim, mainly all to do with the fact that memory reclaim has no > feedback mechanisms to throttle on dirty slab objects that need IO > to reclaim. > > As a result, we currently throttle inode reclaim by issuing IO in > the reclaim context. The unfortunate side effect of this is that it > can cause long tail latencies in reclaim and for some workloads this > can be a problem. > > Now that the shrinkers finally have a method of telling kswapd to > back off, we can start the process of making inode reclaim in XFS > non-blocking. The first thing we need to do is not block kswapd, but > so that doesn't cause immediate serious problems, make sure inode > writeback is always underway when kswapd is running. > > As we don't block kswapd now, we don't have to worry about reclaim > scans taking long delays due to IO being issued and waited for. > Hence while direct reclaim gets delayed by IO, kswapd will not and > so it will keep pushing the AIL to clean inodes. Hence direct > reclaim doesn't need to push the AIL anymore as kswapd will do it > reliably now. > > Signed-off-by: Dave Chinner > --- Reviewed-by: Brian Foster > fs/xfs/xfs_icache.c | 17 ++++++++++++++--- > 1 file changed, 14 insertions(+), 3 deletions(-) > > diff --git a/fs/xfs/xfs_icache.c b/fs/xfs/xfs_icache.c > index 944add5ff8e0..edcc3f6bb3bf 100644 > --- a/fs/xfs/xfs_icache.c > +++ b/fs/xfs/xfs_icache.c > @@ -1378,11 +1378,22 @@ xfs_reclaim_inodes_nr( > struct xfs_mount *mp, > int nr_to_scan) > { > - /* kick background reclaimer and push the AIL */ > + int sync_mode = SYNC_TRYLOCK; > + > + /* kick background reclaimer */ > xfs_reclaim_work_queue(mp); > - xfs_ail_push_all(mp->m_ail); > > - return xfs_reclaim_inodes_ag(mp, SYNC_TRYLOCK | SYNC_WAIT, &nr_to_scan); > + /* > + * For kswapd, we kick background inode writeback. For direct > + * reclaim, we issue and wait on inode writeback to throttle > + * reclaim rates and avoid shouty OOM-death. > + */ > + if (current_is_kswapd()) > + xfs_ail_push_all(mp->m_ail); > + else > + sync_mode |= SYNC_WAIT; > + > + return xfs_reclaim_inodes_ag(mp, sync_mode, &nr_to_scan); > } > > /* > -- > 2.23.0.rc1 >