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=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no 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 2892FECE58E for ; Sat, 12 Oct 2019 00:48:28 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E3248214E0 for ; Sat, 12 Oct 2019 00:48:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E3248214E0 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=fromorbit.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 8F7B96B0003; Fri, 11 Oct 2019 20:48:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8A8386B0005; Fri, 11 Oct 2019 20:48:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 76EB68E0001; Fri, 11 Oct 2019 20:48:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0022.hostedemail.com [216.40.44.22]) by kanga.kvack.org (Postfix) with ESMTP id 5094D6B0003 for ; Fri, 11 Oct 2019 20:48:27 -0400 (EDT) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with SMTP id E8C7D181AC9AE for ; Sat, 12 Oct 2019 00:48:26 +0000 (UTC) X-FDA: 76033296612.07.use73_2c9ab2daf113b X-HE-Tag: use73_2c9ab2daf113b X-Filterd-Recvd-Size: 2608 Received: from mail104.syd.optusnet.com.au (mail104.syd.optusnet.com.au [211.29.132.246]) by imf10.hostedemail.com (Postfix) with ESMTP for ; Sat, 12 Oct 2019 00:48:26 +0000 (UTC) Received: from dread.disaster.area (pa49-181-198-88.pa.nsw.optusnet.com.au [49.181.198.88]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id 3608943EA12; Sat, 12 Oct 2019 11:48:23 +1100 (AEDT) Received: from dave by dread.disaster.area with local (Exim 4.92.2) (envelope-from ) id 1iJ5a1-0008Iw-Qv; Sat, 12 Oct 2019 11:48:21 +1100 Date: Sat, 12 Oct 2019 11:48:21 +1100 From: Dave Chinner To: Josef Bacik Cc: linux-xfs@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH V2 00/26] mm, xfs: non-blocking inode reclaim Message-ID: <20191012004821.GR16973@dread.disaster.area> References: <20191009032124.10541-1-david@fromorbit.com> <20191011190305.towurweq7gsah4vr@macbook-pro-91.dhcp.thefacebook.com> <20191011234842.GQ16973@dread.disaster.area> <20191012001919.lknks3k2at5xpxwf@macbook-pro-91.dhcp.thefacebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191012001919.lknks3k2at5xpxwf@macbook-pro-91.dhcp.thefacebook.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=FNpr/6gs c=1 sm=1 tr=0 a=ocld+OpnWJCUTqzFQA3oTA==:117 a=ocld+OpnWJCUTqzFQA3oTA==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=kj9zAlcOel0A:10 a=XobE76Q3jBoA:10 a=7-415B0cAAAA:8 a=lunlTiudoaBRvRPLOwEA:9 a=CjuIK1q_8ugA:10 a=biEYGPWJfzWAr4FL6Ov7:22 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 Fri, Oct 11, 2019 at 08:19:21PM -0400, Josef Bacik wrote: > Ok, I just read the mm patches and made assumptions about what you were trying > to accomplish. I suppose I should probably dig my stuff back out. Thanks, Fair enough. The mm bits are basically providing backoffs when shrinkers can't make progress for whatever reason (e.g. GFP_NOFS context, requires IO, etc) so that other reclaim scanning can be done while we wait for other progress (like cleaning inodes) can be made before trying to reclaim inodes again. The back-offs are required to prevent priority wind-up and OOM if reclaim progress is extremely slow. These patches aggregate them into bound global reclaim delays between page reclaim and slab shrinking rather than lots of unbound individual delays inside specific shrinkers that end up slowing down the entire slab shrinking scan. Cheers, Dave. -- Dave Chinner david@fromorbit.com