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 CD679C61DA4 for ; Thu, 16 Feb 2023 19:19:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 423C26B0071; Thu, 16 Feb 2023 14:19:57 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3D38F6B0072; Thu, 16 Feb 2023 14:19:57 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2C2776B0073; Thu, 16 Feb 2023 14:19:57 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 1B56C6B0071 for ; Thu, 16 Feb 2023 14:19:57 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id E506A80A58 for ; Thu, 16 Feb 2023 19:19:56 +0000 (UTC) X-FDA: 80474119992.15.1111599 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf01.hostedemail.com (Postfix) with ESMTP id 14F8B40006 for ; Thu, 16 Feb 2023 19:19:54 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=S8VcmUsI; spf=none (imf01.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=1676575195; 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=j0XZ1TS0z/BXWy05oI976Dz35CVag+xasqwyQJopjjA=; b=aqKZxmPbobmkqdK0Gydn95QJCdzLJ/8RaMzYdeIApvF9jkfcoyCXO3bGVBHuYsfW7Zl3ka VDlg3WHaqKC2n2WPU97sX+E3yzuoc68x2QNjIudtv4DkV3kog0ptG/fwX0H9mTKEDeFpzA H79u9ZiZH5ys9NzDEgrKprHSDG+4bSI= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=S8VcmUsI; spf=none (imf01.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=1676575195; a=rsa-sha256; cv=none; b=BXu4kW6tfnft53WtM1RUVY4Cf91WjAGyOaHZClD4YNnzRoOJqxJr1Kl7vAQdVZ6zXKXjKb gXNppYxCPoj7bayNnHzkswIbPb7hegDHXlxHJ73YnvQExcC6deJjI2NJpQeDBblUD6gho3 IUD60Ees2d4M/A02qQH1RlaSjiK5c3I= 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=j0XZ1TS0z/BXWy05oI976Dz35CVag+xasqwyQJopjjA=; b=S8VcmUsIhjLr4j3tKkneCSYUMa cRX+urxQN8VicuyvMKTmAw7bPZpjbKzMhFbq3iBtAT4nM7HeOy0+vxUjPboYB5gU5+ivcp7N7QT7o 9iKkkkfExSVIS6i5r+2Qd70fGuXrMz1EK9CFA5lL/Zl/oXk2wnbPht3RDJt97R5+lWTkEMi4fZg3N mJxJ/w7Eu62Svhd0luYyCZEOOvFr4Nwo9+JN6a4rrYEpExqY8X1HBt31mS5y/aexv/0vAWasDvvIO 5yTD0vCr2ZRXHlTONOTDpSETxsB0wvuhM7bubhC6Kr0lnVefVakwCv+eQS98kUHodqE/jZZv83boA Gf9QQtKg==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1pSjnM-008ecE-1x; Thu, 16 Feb 2023 19:19:52 +0000 Date: Thu, 16 Feb 2023 19:19:52 +0000 From: Matthew Wilcox To: Yin Fengwei Cc: linux-mm@kvack.org Subject: Re: [RFC PATCH 2/2] mm: add zero_user_folio_segments() Message-ID: References: <20230216160528.2146188-1-fengwei.yin@intel.com> <20230216160528.2146188-3-fengwei.yin@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230216160528.2146188-3-fengwei.yin@intel.com> X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 14F8B40006 X-Stat-Signature: 6fdnqm8joposqaoawrjk8ziwt7d8djry X-Rspam-User: X-HE-Tag: 1676575194-56080 X-HE-Meta: U2FsdGVkX19xq6AWuOESply5E9yQHT7/hAEfjropFzybWg+BxGMeEZqDB/tz2euzMbswhNdh8wnAjA69VPdIzD29WBgbbz+1W7EOClfl93T0ztiQWaWBQ9Wpoi0CN/BZsL8a7+6PgOVh9ZrvR7t96OCas8+kL209WLfVUirqfVUh34rmoBNUS8YMe+dUTnsSsHYRs4hRKgDgEYkNXEfvaM/00HUCNlqVovQApDLWXKFg3TnaMuYdFS6dVoV8NGvppCyzatYu9b7WbNMFT8vdL5StUvxveG739mG3gO7qIo53GAokK8vsJUQVAv/pCtII4LS6dT7+Aw8ovxeFiFnP7THp5vLdd+qhrhgNWDwpMnTv3zqOi2dodyabv8kHbEhLkzJNKVt9j+Cw8IDgUgnAqw/vKGniA0eBjZ1IsVnJdJJCUVNmui5wNUm5D2OsYMujK134SF4flAcxf6/WwJKCB2qlbZpSWtMYF8Fgd41/dui0CJzRJir4EShK40DKPuWLENm0xTK4QqA6XFjsI5lbSfWIsjglXeeQZy7gwisiW01uCwrs4jQIC2iN4bjsVP6MVIwta66eg7QMbyatTpv9Q5taKUjVXvXHX8pNHr0lLPv/1CKdep+9/dQw+vdjmSey48Ht5JLjUJCG5UIa98I+Z0+i3zbqz9kwvMtmkjHkTREerPDXcYqoKqnrlyUrjT5wnepzUbciXgyTAIO7MiXOHyuByjYbvx7KC+sudjr6oRpDZA3E2Q2kPbzUgffNic8MHHJ+Txs68h3yItEnLP/xTrgJ+lQqfDXVsynbuWtzTYR8LYpypfVFi9iHCILj/Nl9fhEmIX7/D3RMyxBQQ/BMs9sJ1140HNx4kE5yIPfaQY+/p4EWOx1aI6vIsQan64LVJhcy5z31OtfuhTDBZwxC3tlHUtdRyIFtrbzR86oewwPQZCBsQ+blJ6uP4yJ0YZJFU12sUFwX3E2qGOTXQCa Knxb9hqJ 7DfWHbUuFdR2CaLzRF21H0T9fpHodXWu4EWBqR0M3tNrxMA0/v3ekfrSvPG/Y6yypaEvmK0uQHuIuT3emPqgeeXf2l3AdZG78n1w4ZKQ7MU26YWUI22at6wm5arBE7A8AeJkOWwXeNQ9Ma+NvRhV7yb7cxQEDlDuhq2IbTagIuPIrLnSQMAW2nifim3wlGKdOJYBP 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 Fri, Feb 17, 2023 at 12:05:28AM +0800, Yin Fengwei wrote: > zero_user_folio_segments() has same function as zero_user_segments(). > but take folio as parameter. Update folio_zero_segments(), > folio_zero_segment() and folio_zero_range() to use it. If we were going to do something like this, then it should be folio_zero_segments(), not zero_user_folio_segments(). But I don't understand the advantage to adding this right now. We're adding a new function that does exactly the same thing as zero_user_segments() for no real benefit that I can see. My plan was always to eventually kill off zero_user_segment() zero_user_segments() and zero_user(), and then move the implementation of zero_user_segments() to be the implementation of folio_zero_segments(). But we still have ~100 calls to those three functions, so we can't do that yet. If you're looking for something to do, how about batching calls to page_remove_rmap() in try_to_unmap_one()? That's a pretty hairy function, but I think that you'll see similar gains to the ones you saw with page_add_file_rmap() since it's manipulating the same counters.