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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 84E5DC77B75 for ; Fri, 12 May 2023 15:16:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241683AbjELPQm (ORCPT ); Fri, 12 May 2023 11:16:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60558 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232739AbjELPQl (ORCPT ); Fri, 12 May 2023 11:16:41 -0400 Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 778EA5BA5; Fri, 12 May 2023 08:16:40 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 95F223200907; Fri, 12 May 2023 11:16:39 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Fri, 12 May 2023 11:16:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tycho.pizza; h= cc:cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm3; t=1683904599; x=1683990999; bh=xt kb0nJV/iS7JIfrwakr/gfmwjRljCPV+qLudxkRwvA=; b=sBX9ErKRfkz9Ul1g96 LV+tKo1DkSmM49i8E+NsCfLc9uZA1ibWE5qlYXjZUkoLkc4f+KAO52Y3jpCeB6hr xzS3uPmQFCcRSevNIP29Yf+84wW/iwjpLQy6TY/ZlSGuJmFIY/xnMO3SQFTaQpJF FormSQyKFuvnB10Po/Z4bduNspwBs7f7pAipK6q6zHcnopoRJ5wGNrDC4g75ZM2l skaUdemsMa+iiAxNYS5byhFL69rMFy+UzpNaiRDLkKQGRu86DTUJyif6FxcOnuvC 9Opx1QNWICUcBkmvT12ndteLx3Czy9LX4VIqt11/eUpK02J9+462hbFgL3EBgDJs PXjw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; t=1683904599; x=1683990999; bh=xtkb0nJV/iS7J Ifrwakr/gfmwjRljCPV+qLudxkRwvA=; b=WdXbKy6BLe1bFynIaA8GGQIwotTaw pbWzDihwlD9aVcvLcNQKkInousioevCf1ybERYVHQ2f5WWEAdwRpE0MG3p4JpoiP e29Z+2UL9V88UTVGIqoNrDBBJNJEshG2wSPZhVOxoj9E7wOvY4wV95HYY+wnk0iF QX351PyYZMkDaK3ISmGW9e41bV9QuxG9fKby3kHhewOs5lO1aib2JnL5+wL4ksMH tRVBzwne97msGrMT2TeTuOzpfBhcngoq2ThPjkgSe0iUEAXBOF8nrJ+rkq2wbyZ7 NOgweavZ3ztN2iN52qwUSnKlvs5i74JoWy+3+oQGfJJ4n1uQ+J+h4TI4A== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfeehtddgkeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkfhggtggujgesthdtredttddtvdenucfhrhhomhepvfihtghh ohcutehnuggvrhhsvghnuceothihtghhohesthihtghhohdrphhiiiiirgeqnecuggftrf grthhtvghrnhepueettdetgfejfeffheffffekjeeuveeifeduleegjedutdefffetkeel hfelleetnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epthihtghhohesthihtghhohdrphhiiiiirg X-ME-Proxy: Feedback-ID: i21f147d5:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 12 May 2023 11:16:37 -0400 (EDT) Date: Fri, 12 May 2023 09:16:36 -0600 From: Tycho Andersen To: Dave Chinner Cc: "Darrick J . Wong" , linux-xfs@vger.kernel.org, linux-kernel@vger.kernel.org, Tycho Andersen , "Eric W. Biederman" Subject: Re: [PATCH] xfs: don't do inodgc work if task is exiting Message-ID: References: <20230511151702.14704-1-tycho@tycho.pizza> <20230512014547.GA3223426@dread.disaster.area> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230512014547.GA3223426@dread.disaster.area> Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org On Fri, May 12, 2023 at 11:45:47AM +1000, Dave Chinner wrote: > > Yeah, this is papering over the observed symptom, not addressing the > root cause of the inodegc flush delay. What do you see when you run > sysrq-w and sysrq-l? Are there inodegc worker threads blocked > performing inodegc? I will try this next time we encounter this. > e.g. inodegc flushes could simply be delayed by an unlinked inode > being processed that has millions of extents that need to be freed. > > In reality, inode reclaim can block for long periods of time > on any filesystem, so the concept of "inode reclaim should > not block when PF_EXITING" is not a behaviour that we guarantee > anywhere or could guarantee across the board. > > Let's get to the bottom of why inodegc has apparently stalled before > trying to work out how to fix it... I'm happy to try, but I think it is also worth applying this patch. Like I said in the other thread, having to evac a box to get rid of an unkillable userspace process is annoying. Thanks for the debugging tips. Tycho