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 3123AC54798 for ; Tue, 27 Feb 2024 16:07:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B031C280025; Tue, 27 Feb 2024 11:07:00 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A8BCC28001D; Tue, 27 Feb 2024 11:07:00 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 90784280025; Tue, 27 Feb 2024 11:07:00 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 7BAC228001D for ; Tue, 27 Feb 2024 11:07:00 -0500 (EST) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 4A52D1C0DD5 for ; Tue, 27 Feb 2024 16:07:00 +0000 (UTC) X-FDA: 81838062600.16.CC1C158 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf29.hostedemail.com (Postfix) with ESMTP id C4678120012 for ; Tue, 27 Feb 2024 16:06:57 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=uoARtJF5; spf=pass (imf29.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"; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709050018; a=rsa-sha256; cv=none; b=MLgvawrI5v/8BOFsZM79knzUqrNT/ESGObYtXnsLssipLxCS9KJ/pbnFYsOWSwB/cMt0UT iw/xOBvP9IUk7txqBy8qrhj7U95zxA+tsVNlkHAsWVkqzgEqCr1aM+431cYDS9685AbrOJ Aqx8EhK1M+0e+zgc4JUZARL84crotoE= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=uoARtJF5; spf=pass (imf29.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"; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709050018; 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=cw6+EUCM9bZHbIICqfc6tX3opYwo9jWkZmloDuzyXK8=; b=uTjQOrtMG8lgiWQh38XNdmgUSXjG3SH6cJkFUhbQ2AomuSzV9EUlMmIZjlYMTN+Mxfm2CK IUAwyr2ggQAWMpTs8sxE3wNSAmugJ3FSNUuxMf6lQZPaWAkKH1OAX5P1juU9kXDFnRKSqO kMI+P4wzSCr5spPDgpP4tJ67vGkUejo= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id F09AFCE1C71; Tue, 27 Feb 2024 16:06:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 37972C433F1; Tue, 27 Feb 2024 16:06:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1709050013; bh=CGtGmL1FfoSdaXDRarwBLqvpH7xazho5uBvNzP5U/Rc=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=uoARtJF5eNoTHuTfd77RG6I4DKny53qG2RL8fBxGYNb5r9QqHUD8rVA0VeqDFDWTy tbVpdy5G/9FKxj2vMIlWDfExk0tW1cnQV1Po/0BSRXyyOlY5QXeyo85UhLwYcaLNtd E5ReQsYRz5PnYAmDXDxLcu7uLFA/DELh2sUvevZ2FTZEnAAwGySd+XpmH4j5dX0c6C UsDsPqKcBKvxCBv1MpiataibW/CxC1IS7LRNzm0pCK6IeQ4RyjmmbitEJRpAGLUW7F G1H46qqcZGYsOs4E8H52uThu2nQGPWt/XUhcXHyjem9L09PUVvPNeDmEi9FZ93J5zp lE7Uhgo96aEOA== Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id C5FFACE0F12; Tue, 27 Feb 2024 08:06:52 -0800 (PST) Date: Tue, 27 Feb 2024 08:06:52 -0800 From: "Paul E. McKenney" To: Kent Overstreet Cc: Matthew Wilcox , 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: <3c16052d-8e4c-4af7-ae82-f47ee058a884@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-Server: rspam08 X-Rspamd-Queue-Id: C4678120012 X-Stat-Signature: fr9q1tb186kgsam6685tzdckdzpgcid7 X-Rspam-User: X-HE-Tag: 1709050017-46082 X-HE-Meta: U2FsdGVkX1+uym8QWkE0A2tZwYE29TUiDjtZ9QMh2whdc1FgiIMtj4GDCPgyvsQTeThdWJph9nwXYXavp8y9GSTrXoyKG2iPK6vFRE5DTZzC7xTXeh/3YGV8b/YEbfdFrvT9SiYuNoRHpfh1SeywrB57JtmTLkiYPIEnHPetAfaRpH03t8jXQLtQl3Frt+y+Y/84bplonvscjVYmAnHkH7cO+k64uAFo1x3HCqNzN5ahFgqzs8R6Pm8bJw2z1X6QzkjcZxRUB2N9bRpHlyBC0gU1cUs5Q3Mdvz1MVq/5pVtlo0l4pwIPpFTVu0tXK3sf+6tBBeEdVft/VftCe2JRdbbi5yfxqPZDh98IGqcymiIKAOFgEsCr9CC0LMzT4Hh1+ili4D2oXhXW2TPzpuYcmnT+E5JuWOMyBJ9LMODL4DTDkPlLYbpok7c+nPedkikk0HQL5JWbiXgY2Pds48nSgu9Z4TDYkAfu9Na3MElL5WF5EnaFN9aU+dUiAK5y0Cwc7giV0p7AR09GKeOF55Knfv8yMKxerxx06bOeuLJxdT38q0IEFZ9iXwXo+6+DUCosxd4qTdy3SAakZf/cXZuqu2c9SZpoo4A9tTxpGoo7o8HykWLGUK6ZkVcAYaUItXVw1Lxc5UPjs6oiwHOT6J4Noay4EOkuVMF2BXJjync06/HZRfBHSGPLaiSh5Q538HovFKmpwc0D7mQ23pTWjRPmHpXXXmO6e1FvjVsADMW8pPl79LFBvXDo+pIJ3MV8qrCxbOWDQz1Ei70oHmooz1orbIeHc5yY7fQ3disTJz6Q+NO+Ysj4n6V7zczzEkkv4W3wzz3NHbUmnN3CpawX+b8WNSWkC9Gv8F153rt9aBK0WMDj4NO2bLjjkWovwRgEUXDV7yqXuXKeFIRX1q++uurd4Q+UsXlFt1jnOdw9/WFbhJ81TJLx+Udlt+ZRREmE3kBLJd7i7VQLdKawtb75ZWH 3Oe6W9MW HGOSpMdirQPedUtJLLl8pQssLk++5LgTDzMdgW5CL2ek+NwqR8MkdJbyqwfVe23+8z7MboZAeuXmbMJQwttt/7R4hbcEELqxqu7qiBd2I4ZGbc27QOhU9acS2z0tScuQNS0BXIucx86dmQz6sGNjKPffSDlXEH7Gloip6vsP8Q94I4RCcIfpHdrQfP7liO/l124WFIKok/xp4HMZhZxC2Dujpi0L2h6uGl0STA4rXcmVDcLqityqS6mq/ZYNsp9sW11qMDAvCvsNzVCE14z1Ba54cUhoQi2w2gVQEjlfJgxwMR2NMAVc9J2USLN0PSvBEoWH498nOEPJR2nP50ux0g4K4BZMfzOLp2mnt9CZf3ZYrF4yXMK16uGFd+m2If41WAavb+/E3zUZpL7qPnBKVb42Zl4y6LpHq/L1qRPl+XTwjppMF2wsPt2JlJlrn5bd6bytbhTrWajwdrTrdxWO6TVfWxnOTway8bUAIB0G0b+Rw/V9V+9jOtc9A3Vp5EMcKZxy7s6j6inBjc8jwSfvrA/Od+PH+uKSxTTRC 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 10:52:51AM -0500, Kent Overstreet wrote: > On Tue, Feb 27, 2024 at 07:32:32AM -0800, Paul E. McKenney wrote: > > I could simply use the same general approach that I use within RCU > > itself, which currently has absolutely no idea how much memory (if any) > > that each callback will free. Especially given that some callbacks > > free groups of memory blocks, while other free nothing. ;-) > > > > Alternatively, we could gather statistics on the amount of memory freed > > by each callback and use that as an estimate. > > > > But we should instead step back and ask exactly what we are trying to > > accomplish here, which just might be what Dave Chinner was getting at. > > > > 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. > > > > So, where does RCU fit in? > > > > RCU fits in between the two. With memory awaiting RCU, there is no need > > to write anything out, but there is a delay. As such, memory waiting > > for an RCU grace period is similar to memory that is to be reclaimed > > after its I/O completes. > > > > One complication, and a complication that we are considering exploiting, > > is that, unlike reclaimable memory waiting for I/O, we could often > > (but not always) have some control over how quickly RCU's grace periods > > complete. And we already do this programmatically by using the choice > > between sychronize_rcu() and synchronize_rcu_expedited(). The question > > is whether we should expedite normal RCU grace periods during reclaim, > > and if so, under what conditions. > > > > You identified one potential condition, namely the amount of memory > > waiting to be reclaimed. One complication with this approach is that RCU > > has no idea how much memory each callback represents, and for call_rcu(), > > there is no way for it to find out. For kfree_rcu(), there are ways, > > but as you know, I am questioning whether those ways are reasonable from > > a performance perspective. But even if they are, we would be accepting > > more error from the memory waiting via call_rcu() than we would be > > accepting if we just counted blocks instead of bytes for kfree_rcu(). > > You're _way_ overcomplicating this. Sorry, but no. Please read the remainder of my prior email carefully. Thanx, Paul > The relevant thing to consider is the relative cost of __ksize() and > kfree_rcu(). __ksize() is already pretty cheap, and with slab gone and > space available in struct slab we can get it down to a single load. > > > Let me reiterate that: The estimation error that you are objecting to > > for kfree_rcu() is completely and utterly unavoidable for call_rcu(). > > hardly, callsites manually freeing memory manually after an RCU grace > period can do the accounting manually - if they're hot enough to matter, > most aren.t > > and with memory allocation profiling coming, which also tracks # of > allocations, we'll also have an easy way to spot those.