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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id BCDA4C5478C for ; Tue, 27 Feb 2024 16:21:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3916628002A; Tue, 27 Feb 2024 11:21:36 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3416D28001D; Tue, 27 Feb 2024 11:21:36 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1E21628002A; Tue, 27 Feb 2024 11:21:36 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 079BE28001D for ; Tue, 27 Feb 2024 11:21:36 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id D0CD1140C33 for ; Tue, 27 Feb 2024 16:21:35 +0000 (UTC) X-FDA: 81838099350.14.E6024C3 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf30.hostedemail.com (Postfix) with ESMTP id 981C38001D for ; Tue, 27 Feb 2024 16:21:33 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=kdv0Elu8; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf30.hostedemail.com: domain of "SRS0=xPBP=KE=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" designates 145.40.73.55 as permitted sender) smtp.mailfrom="SRS0=xPBP=KE=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709050894; h=from:from:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=UqqGXErNZll7f3uxMbyEyMPA1dmjPz1Vd+9uvYtAJP8=; b=ogM9NKMnJf38GlKhU5d+YjSlx2xlb30RnocpIm35UupSOUJq945Q1NYQndRhIyns9N6OEU 2ThrlGZAmKme9CJ8tf4V4LjYIH9lT5tql9uRg+4FdJ29PujGBipA2Jjo9VCfLEM7Rnx7yk 97L5pfQiK/cuiGuhM77xB0SL4w1Hzsc= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=kdv0Elu8; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf30.hostedemail.com: domain of "SRS0=xPBP=KE=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" designates 145.40.73.55 as permitted sender) smtp.mailfrom="SRS0=xPBP=KE=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709050894; a=rsa-sha256; cv=none; b=r2+qREmPF/rqyinIb+A3pU4ZA30i1Cek24x0bINdwdfYcLYPwz/wbK7o8so1vMX1EhmOMh qBfNTBCmXDmP1ySfJaOWgfK+PsvAGqHiG180wWpBdN4QZWWwyeso5Tyw6xMrHWsr5J+1Iv m1vLjIvKpTE8khhxYsL3sg00rahM1E0= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 66C1CCE1BB6; Tue, 27 Feb 2024 16:21:30 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9C8C9C433C7; Tue, 27 Feb 2024 16:21:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1709050889; bh=Hzg6zefAGU5YFBT8ZyU0GJNb+Waa5u+eZRrV8mqCzvY=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=kdv0Elu8z2EC15UsAezT6BWoezSHq5bGjRQ7d7TbhaAQggXcgRpu/BjIHQiLX6DrY WjBoWHxqOSKvieJHw8EGHlkIzEvdP3H0zo355eiivFQFT848J1TRgAm/vf51lDYZU+ AgZkjMRUrRfdLgctP9dPkKB+fcTPnoSGEhlvzV4hqAjM8SsFHE4sF808+fk+Stvki3 /BR6VQDGlCI9IaCIvpqfR0DAgMicEbnakhVNIrrLhJVefOmoaXbD4ppdSRe+PYGdqP d0BiomBHQKQPUiu7prrZud84e6LyidITFxhuRl7N9qZGDJ9GnISy0qRhaPA5Po9jCk HTUJf7bgiEpnQ== Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id 391B0CE0F12; Tue, 27 Feb 2024 08:21:29 -0800 (PST) Date: Tue, 27 Feb 2024 08:21:29 -0800 From: "Paul E. McKenney" To: Matthew Wilcox Cc: Kent Overstreet , Linus Torvalds , Al Viro , Luis Chamberlain , lsf-pc@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-mm , Daniel Gomez , Pankaj Raghav , Jens Axboe , Dave Chinner , Christoph Hellwig , Chris Mason , Johannes Weiner Subject: Re: [LSF/MM/BPF TOPIC] Measuring limits and enhancing buffered IO Message-ID: <1f0d0536-c35b-46f9-9dfb-c8bc29e6956a@paulmck-laptop> Reply-To: paulmck@kernel.org References: <5c6ueuv5vlyir76yssuwmfmfuof3ukxz6h5hkyzfvsm2wkncrl@7wvkfpmvy2gp> <49354148-4dea-4c89-b591-76b21ed4a5d1@paulmck-laptop> <6xpyltamnbd7q7nesntqspyfjfq3jexkmfyj2fekrk2mrhktcr@73vij67d5vne> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 981C38001D X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: s9ens65ra4ekobemt1ty377cn45hh145 X-HE-Tag: 1709050893-257453 X-HE-Meta: U2FsdGVkX1+biEhhqI2zO0KJro9HKG7bmkv4lrzp6G7F9S8fBHTrYeDxPrAm14PUbRqX+wbuTx3YEATOU8cNTpvIA7ptA9Z9yY1wkVEqPUKhhuJppr8Gjhda7GmLmdK/P6sw7T5t3Bpb7No43JyrywDXcPiHTaIiAtmi8XyRx9FvxSlmRmtUswcbYYibkUwGmKC4sO73W6UdDKNZ/WOFgiHhw1Vmi6oip2xuhBM1ypWrE66Aj51+LFp/9WBC4dpWZH8fc/dib6rHkU0JYA8TcUtUwL6dA9AtQjCiGVxR0nJ7DA3ieCscNpi9RCO4ea3NLa7Hs2cswVRG8K6vWzm75TJulLAOw9hqFO4Yd04zNoAHweWWklKr8W+iL4zZw9N2NzgSXddYW3eQ1SxE+ANLBAvcw3tf2YgysMcoIli6GkmINlk4Dicl7ipOgoNMUluR5MDZ1BRXz2anFkmZJULq09Kjkvr6FqymmSWulaKs5o2Nj+wEOD5ExXTT00fiyK/Ll94pCsLwFueN7LrG0/bOAT5ZRkbmAiNeIIIEtaWx1b5/A52z8XkiMzOZcj2qTRMWZmwyg1/VYtBzaq2uEE5NccFnBFZRB4Y2Lt0GXLxK1T9NUod94hpvWNOaDt9t/7EpyNfOUAQaUdTkiMrvkwxTXNw1z6RiOYpGhcP6LTdQxfjfie2o+jIPOpTcHDr4zUOU2OS3hYKTKRJmubR64DlO4z7qN52BPi3FRTcJ61vRzRz/vXjnZmAE5ZfFcS8YTFqFY14lk2DB6r8gBsIn5L6H5hWR2/PQ2fVKpPvktCzVQRBGg6AijzSvxwQ2mVv6Enht0c9ufeHLmLPctR7f4PwHWuKABk9F8buZdJH+vv5BmimwVo17D7H1W9zRxL28ZnfpPNGkmKwr9GR8FYbfxDP1BTlx1cq7yuIUR2LA5jOF+tw2l7u+LJ8E64r3d5XNNWSS6YA7ujHCvmn7lcrylU7 vnpJZu2B n6/HvmJBYlzMnLfXEU44V25bejYTyIcWRJPRXx3k7wnxL/hqUmEkjq9XTzcIhIbFthKjXb3BLAZQQ/5pdjSCkLS0V960s6IMZmim4xSsrlrfJszIfi3QcpFv3ZPmlmpW/toOsvLZlZWpUGhSm6wmYR8Y0jF+TDtAHzU/hbUQqHWHabczXjEzpUQB3fb6cxI1mGsWAjOHEly9Y073Dgh9XqCuhDqErhwrKxxFEn/dZ7wwbJJoblfVLA3X/zGXSKL0Mqib9JRtm2hBG8RE= 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: List-Subscribe: List-Unsubscribe: On Tue, Feb 27, 2024 at 03:54:23PM +0000, Matthew Wilcox wrote: > On Tue, Feb 27, 2024 at 07:32:32AM -0800, Paul E. McKenney wrote: > > At a ridiculously high level, reclaim is looking for memory to free. > > Some read-only memory can often be dropped immediately on the grounds > > that its data can be read back in if needed. Other memory can only be > > dropped after being written out, which involves a delay. There are of > > course many other complications, but this will do for a start. > > Hi Paul, > > I appreciate the necessity of describing what's going on at a very high > level, but there's a wrinkle that I'm not sure you're aware of which > may substantially change your argument. > > For anonymous memory, we do indeed wait until reclaim to start writing it > to swap. That may or may not be the right approach given how anonymous > memory is used (and could be the topic of an interesting discussion > at LSFMM). > > For file-backed memory, we do not write back memory in reclaim. If it > has got to the point of calling ->writepage in vmscan, things have gone > horribly wrong to the point where calling ->writepage will make things > worse. This is why we're currently removing ->writepage from every > filesystem (only ->writepages will remain). Instead, the page cache > is written back much earlier, once we get to balance_dirty_pages(). > That lets us write pages in filesystem-friendly ways instead of in MM > LRU order. Thank you for the additional details. But please allow me to further summarize the point of my prior email that seems to be getting lost: 1. RCU already does significant work prodding grace periods. 2. There is no reasonable way to provide estimates of the memory sent to RCU via call_rcu(), and in many cases the bulk of the waiting memory will be call_rcu() memory. Therefore, if we cannot come up with a heuristic that does not need to know the bytes of memory waiting, we are stuck anyway. So perhaps the proper heuristic for RCU speeding things up is simply "Hey RCU, we are in reclaim!". Or do you have hard data showing that this is insufficient? Thanx, Paul