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 42A6FC19F32 for ; Wed, 5 Mar 2025 18:30:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 746CE6B0082; Wed, 5 Mar 2025 13:29:17 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6F4776B0083; Wed, 5 Mar 2025 13:29:17 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5BB056B0085; Wed, 5 Mar 2025 13:29:17 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 1B6B06B0082 for ; Wed, 5 Mar 2025 13:29:17 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 51CF154EBE for ; Wed, 5 Mar 2025 18:11:33 +0000 (UTC) X-FDA: 83188290066.11.8A6B6BD Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf29.hostedemail.com (Postfix) with ESMTP id D7DCD12000D for ; Wed, 5 Mar 2025 18:11:29 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=IgSfPWUc; spf=none (imf29.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741198291; h=from:from:sender: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=F7TU3bjLM7Kk9wjHsOCNvuPzJqYTbP5q9iK8ewQzVcQ=; b=6qXME5ggEiCTG+GZBSVXxm3v5KDADjsz7lHbxeNZc7taioIsIHUFi0fo2ZjLEieieX27pX 0uJGyu/irU3BfLSTy1nA8iOkDCQVIP5AvPlfaBAOBHhgVlv1k59Wh/CMh4jQyOfngtUpmI RaiBTeOn+NaccN6250ki0bO3nOPqEFk= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=IgSfPWUc; spf=none (imf29.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741198291; a=rsa-sha256; cv=none; b=hr6N94DCKs6MH6ibW7L76BOD4v+9adTzvHa+eCv/KnLezyx78Xxwr2WqM1+7HmXVkpDMLC 4vWCpvGuf2dfFdpc3vL5w6VRT/WDlOPZP14AFn07mc6Lb07yrCtSo0/c+fuJ2oY8hC1Ab1 TeuiM1S6B30ZcvhkoJpGnK5pXVj7Xko= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=F7TU3bjLM7Kk9wjHsOCNvuPzJqYTbP5q9iK8ewQzVcQ=; b=IgSfPWUcfV/nOKNGVnqs2/fVCy s7dYvyuf7GrdM2LlrzACrgBe5KNPB0fXPHNxfHP0C+aKXPzRgZrSLvZGb7ueo/dfMa1fmPivOHie2 BRv5fC4REUKx0FFNE8GSVKE4gp9p/YMJQ6eO0QvaDhWredhqa7ZdDFjWmq+8EY+XmFsLg1VOfHtmC sZMRS6Dt1ySdNKExAzX/DaNZupo6eUwej0n5v41ErZfsi5D9Y8BaBRT5H2P8rlqzf4jRnMnLgtush fws/3jWYDIvOSn10BXc5Gbrc5fsaw8TYiI51R1FV1Y5ulwZoho820CotEXb0nQ3ClR62JhBoWsDMr UUZLX4eg==; Received: from willy by casper.infradead.org with local (Exim 4.98 #2 (Red Hat Linux)) id 1tptDI-00000005zFf-1Ztk; Wed, 05 Mar 2025 18:11:24 +0000 Date: Wed, 5 Mar 2025 18:11:24 +0000 From: Matthew Wilcox To: Hannes Reinecke Cc: Vlastimil Babka , Hannes Reinecke , Boris Pismenny , John Fastabend , Jakub Kicinski , Sagi Grimberg , "linux-nvme@lists.infradead.org" , "linux-block@vger.kernel.org" , linux-mm@kvack.org, Harry Yoo , "netdev@vger.kernel.org" Subject: Networking people smell funny and make poor life choices Message-ID: References: <27111897-0b36-4d8c-8be9-4f8bdbae88b7@suse.cz> <7439cb2f-6a97-494b-aa10-e9bebb218b58@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7439cb2f-6a97-494b-aa10-e9bebb218b58@suse.de> X-Rspam-User: X-Rspamd-Queue-Id: D7DCD12000D X-Rspamd-Server: rspam09 X-Stat-Signature: ci59mhnxqewszbcfeq14xeskyc3r5mc1 X-HE-Tag: 1741198289-273773 X-HE-Meta: U2FsdGVkX19X7q18r9eQj2V1ALEDUxssebhLly47jZT+NoEVgM9K30AWE9W6Kblb8VkMOSWPTM8ODmhHbt4V+YHyDaWKOSGKqapiVFCpS4iSfxxFRwwulcUyJ5Qh6YaTCl7MkV64loybv6r4lir0fAHpU/QjZnqFnL3ruA7v4ehSRNXPOFzsNBKVp1blr6nL25VHjp676zAZES8vdncVVc4GDF7bM9DWnvUcC4T/G1fF8Pe5L9fNx7qKC7W4KomHtDx8s0GUmYiqSKKgdhVG5S8s6aTVlFYz+2iht/UxWpMZ248SK5S0WqMHLyLC3E9EaNpGKyqCrfKDU1JxBg1e15SJKvcjl1hrBkwTWF1uhJNjnzEZ/cQcEGgD8sV/83OOwNQabgc2qQKt5mfov+L17btWOo5Ynrt+nt3OwKODLl07V24NIl5UvPJKFhoLiIf1b6j6qCc+jlcdTpc/78bpvKrmlDfWDGw3tO15Dd6lJrNR18QFVUjcbIA6/0Dc+3tfmId8Qi1ebu5RgM/G4DOT/9Pa5JRp0E+8wOty1lkvKuM8zFfJInxp2rWNx7GZ3/ouDj7+j1hyFt8c8RXx/L13bQk0mfiZj8lAqL4/2B2nwd6KJ+LfEcjYQg+rPJJ6K2AQD6ZWNoX8fh5YEWAM8dVWqC7Ncxfqj9EeqEeS2u/5O2OQ7lSRh1x3evWHi4Y/Q7Od/sCjbZrcwE+kMiypS8/j0fbWnDA6ROfuRmU7L2PudePASb2C3kR8DYPnyT9G6X72ekyKE+HlOsUfef2GJdWDe7pDiAHk2dRPalTXoChDYxdOa4BIS7ygUJkb1FuwfPV6W4U/K2UB0V0JELzKG+BKIjKaAdx7W+biZ8tqSIJ4LgLgxh/eyKyjcy/6AjGyA8AHxlEygQLgLvJYcOZU28knLMUBTmdTXelNVFsDKpD9x6NjyD40nSadlZuH3cTrIt209qZRO8/FoXXV6WucSrv bH7iN0V3 Wy8Kv3FvofLYg7zcCR2YDOhzYw4GPrtIwB520X7UFD/+Asu1bN+rlRFRHYrMD3X2iH86ryLlFjKn+aZLeLBdv5zUcoHG8EHCAI/GIGv1SJctHXwXj20PJd4qGZZIrgljS/qLvJebDEW3Gpqrl0guN7jVve5hQWhSJtDhwbS0MdU8RNUyR+MU8p2opeoD2/QmTtcS/l3f7u3KVvHpjgD/k9Y0RNo8QeicHy3or9lmSsm3EMMdgF2NqaeeJL8J2+7BmlkDxIEKnnZyj0kO4wCV0tknJi2tao0z9MmrS6+uiaTr9sKVIyrEgA87OLDYiW7kJ3gEMnKtk/D8NPP4CQkXIa0+H+g== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000470, 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 Wed, Mar 05, 2025 at 12:43:02PM +0100, Hannes Reinecke wrote: > Oh, sure. But what annoys me: why do we have to care? > > When doing I/O _all_ data is stuffed into bvecs via > bio_add_page(), and after that information about the > origin is lost; any iteration on the bio will be a bvec > iteration. > Previously we could just do a bvec iteration, get a reference > for each page, and start processing. > Now suddenly the caller has to check if it's a slab page and don't > get a reference for that. Not only that, he also has to remember > to _not_ drop the reference when he's done. > And, of course, tracing get_page() and the corresponding put_page() > calls through all the layers. Networking needs to follow block's lead and STOP GETTING REFCOUNTS ON PAGES. That will speed up networking (eliminates two atomic operations per page). And of course, it will eliminate this hack in the MM. I think we do need to put this hack into the MM for now, but it needs to go away again as quickly as possible. What worries me is that nobody in networking has replied to this thread yet. Do they not care? Let's see if a subject line change will help with that.