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.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,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 1D20CCA9EA9 for ; Fri, 18 Oct 2019 20:29:34 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B73B82054F for ; Fri, 18 Oct 2019 20:29:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B73B82054F 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 F24578E0005; Fri, 18 Oct 2019 16:29:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id ED3D88E0003; Fri, 18 Oct 2019 16:29:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E120B8E0005; Fri, 18 Oct 2019 16:29:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0192.hostedemail.com [216.40.44.192]) by kanga.kvack.org (Postfix) with ESMTP id C18908E0003 for ; Fri, 18 Oct 2019 16:29:32 -0400 (EDT) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id 62B6653B4 for ; Fri, 18 Oct 2019 20:29:32 +0000 (UTC) X-FDA: 76058045784.10.wren89_533970b4a5e25 X-HE-Tag: wren89_533970b4a5e25 X-Filterd-Recvd-Size: 2912 Received: from mail105.syd.optusnet.com.au (mail105.syd.optusnet.com.au [211.29.132.249]) by imf18.hostedemail.com (Postfix) with ESMTP for ; Fri, 18 Oct 2019 20:29:31 +0000 (UTC) Received: from dread.disaster.area (pa49-179-0-183.pa.nsw.optusnet.com.au [49.179.0.183]) by mail105.syd.optusnet.com.au (Postfix) with ESMTPS id D87D93638E6; Sat, 19 Oct 2019 07:29:28 +1100 (AEDT) Received: from dave by dread.disaster.area with local (Exim 4.92.2) (envelope-from ) id 1iLYsJ-0002Bf-R3; Sat, 19 Oct 2019 07:29:27 +1100 Date: Sat, 19 Oct 2019 07:29:27 +1100 From: Dave Chinner To: Brian Foster Cc: linux-xfs@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH 25/26] xfs: rework unreferenced inode lookups Message-ID: <20191018202927.GQ16973@dread.disaster.area> References: <20191009032124.10541-1-david@fromorbit.com> <20191009032124.10541-26-david@fromorbit.com> <20191014130719.GE12380@bfoster> <20191017012438.GK16973@dread.disaster.area> <20191017075729.GA19442@bfoster> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191017075729.GA19442@bfoster> User-Agent: Mutt/1.10.1 (2018-07-13) X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=D+Q3ErZj c=1 sm=1 tr=0 a=52fyy8O0dbGPTevbDZN8bg==:117 a=52fyy8O0dbGPTevbDZN8bg==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=kj9zAlcOel0A:10 a=XobE76Q3jBoA:10 a=7-415B0cAAAA:8 a=2sWhKzXocK4_PVnBHZEA:9 a=hOR0AJh8QWLIpmh6:21 a=lVIhb6QhHtTIAenZ:21 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 Thu, Oct 17, 2019 at 03:57:29AM -0400, Brian Foster wrote: > On Thu, Oct 17, 2019 at 12:24:38PM +1100, Dave Chinner wrote: > > It's not a contention issue - there's real bugs if we don't order > > the locking correctly here. > > > > Is this patch fixing real bugs in the existing code or reducing > contention/blocking in the reclaim codepath? My understanding was the > latter, so thus I'm trying to make sure I follow how this blocking can > actually happen that this patch purports to address. The reasoning in my > comment above is basically how I followed the existing code as it > pertains to blocking in reclaim, and that is the scenario I was asking > about... Neither. It's a patch that simplifies and formalises the unreferenced inode lookup alogrithm. Previous patches change the way we isolate inodes for reclaim, opening up the opportunity to simplify the lookup/reclaim synchronisation and remove a race condition that that we've carried a workaround to avoid for 20+ years. Yes, it has the added bonus of removing a potential blocking point in reclaim, but hitting that blocking point it is pretty rare so it's not really a reduction in anything measurable. Cheers, Dave. -- Dave Chinner david@fromorbit.com