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 8BFA8CEF16B for ; Tue, 8 Oct 2024 12:57:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A57886B007B; Tue, 8 Oct 2024 08:57:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A02916B0083; Tue, 8 Oct 2024 08:57:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8A3566B0085; Tue, 8 Oct 2024 08:57:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 6C1E56B007B for ; Tue, 8 Oct 2024 08:57:53 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 7FD41ACC3E for ; Tue, 8 Oct 2024 12:57:50 +0000 (UTC) X-FDA: 82650437226.05.539A2B1 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by imf24.hostedemail.com (Postfix) with ESMTP id 9DC4A18000D for ; Tue, 8 Oct 2024 12:57:50 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b="lUDijd/O"; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b="de/xni6+"; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b="lUDijd/O"; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b="de/xni6+"; spf=pass (imf24.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.131 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1728392091; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=LHNP9INoNCBmPOSJpiOK8YZZ1XwabaP1uf1xaEwjuKs=; b=y9WbgN0E0OzVzwoNlRTQrEXeC4JpAWeeH9BuBRKXEZlWgfi2GH929J90BHdg4IvGI5Lil0 CGK5DkasIey4KRBvq410NpiB3L5IWjwbzWzISX4QU3kTF0wNXCC83mLRWIy8xdML0LqFXb KiJdac68dOpX5v9NmjB88kBGFNqezq8= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b="lUDijd/O"; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b="de/xni6+"; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b="lUDijd/O"; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b="de/xni6+"; spf=pass (imf24.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.131 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1728392091; a=rsa-sha256; cv=none; b=PRFqNOSXraheYgqJOAWDYTRXshqxMK4w8AP0P6O/8G0oV+IsvqrPA39jRnxXlHIfNZ/+mH wQqGfiSXzap4xrrzmfoso5Mo6kOOKxvdroqgRnhntFYPMWrVysDkQOq44Gwr+IpilkDvMn TvSdPh9KVIXAB+soiicGD9x2/NeS/Ug= Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 7AAA71FB53; Tue, 8 Oct 2024 12:57:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1728392268; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=LHNP9INoNCBmPOSJpiOK8YZZ1XwabaP1uf1xaEwjuKs=; b=lUDijd/OgQR/9fXkmUdKSa1ii/ZTQGfO7gNY1yBwqo+EYdXdaiJcTnIrBoZ+IenCDbLp6g pHefgUDs4FcgN3xBX69w37sc6R3dJwmIKUO4TKRH67VLM3ZoZ3SRKPuW2zzQT13t+2fjNf ZV6JVi6pdfOGpQW4d/A680WLqAFdLtc= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1728392268; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=LHNP9INoNCBmPOSJpiOK8YZZ1XwabaP1uf1xaEwjuKs=; b=de/xni6+TOL5AOpGWdRaONUZ7sgMLb9HoOKvyjkXVyjoG/eLFVmvVXoajZFbWQz2nI7vAe TpoeX9259vZzE2CQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1728392268; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=LHNP9INoNCBmPOSJpiOK8YZZ1XwabaP1uf1xaEwjuKs=; b=lUDijd/OgQR/9fXkmUdKSa1ii/ZTQGfO7gNY1yBwqo+EYdXdaiJcTnIrBoZ+IenCDbLp6g pHefgUDs4FcgN3xBX69w37sc6R3dJwmIKUO4TKRH67VLM3ZoZ3SRKPuW2zzQT13t+2fjNf ZV6JVi6pdfOGpQW4d/A680WLqAFdLtc= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1728392268; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=LHNP9INoNCBmPOSJpiOK8YZZ1XwabaP1uf1xaEwjuKs=; b=de/xni6+TOL5AOpGWdRaONUZ7sgMLb9HoOKvyjkXVyjoG/eLFVmvVXoajZFbWQz2nI7vAe TpoeX9259vZzE2CQ== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 5BACF137CF; Tue, 8 Oct 2024 12:57:48 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id BdunFUwsBWfLfwAAD6G6ig (envelope-from ); Tue, 08 Oct 2024 12:57:48 +0000 Message-ID: Date: Tue, 8 Oct 2024 14:57:48 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH] mm: avoid clearing user movable page twice with init_on_alloc=1 Content-Language: en-US To: Zi Yan , David Hildenbrand Cc: linux-mm@kvack.org, Alexander Potapenko , Kees Cook , Andrew Morton , "Matthew Wilcox (Oracle)" , Miaohe Lin , Kefeng Wang , John Hubbard , "Huang, Ying" , linux-kernel@vger.kernel.org References: <20241007182315.401167-1-ziy@nvidia.com> <9e4e3094-00a2-43bc-996f-af15c3168e3a@redhat.com> <84D24C40-AC10-4FF7-B5F6-63FADD523297@nvidia.com> From: Vlastimil Babka In-Reply-To: <84D24C40-AC10-4FF7-B5F6-63FADD523297@nvidia.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Action: no action X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 9DC4A18000D X-Stat-Signature: wbztnig6qht11kiqymberywwpa95dyrs X-Rspam-User: X-HE-Tag: 1728392270-436038 X-HE-Meta: U2FsdGVkX1+AcF5ErDXvEhg1wZDgQfp4E0+rK5SsK1x9iERjcPEA0JCIfc9KRBZ9bt7ALe70O51mlmB9xBCiodvgOJ0b072yfWwr1tudiFl8HuZ+/QK/Kn0hdSNt6OwKGuy4jwNGDmc02fJCMi/MlhRmvQNX4mSZRnEqghXcaqhNIJ73gxVxtX1gH3yxSRx55//6oNRaEK5fSwLNKRASQ/zJIJJdHFuMUUhLEWydV/1gL2MAF9OCkWRfo++X3cyQ35Lv2lp1zVsqhXkJnVUaLWCHj8XE7eo3QQb2WvbxTgLHwOJPU2paTACWDz0molepMENRseoQno5Nt+inlNzmFhRPR33GnaAxUYlTHE4aLKM8wN84o72ev7Js7CGN4vnNiQEEL4J3iwzhtm72nZFzugZyNYTv80osPAgQHj0D6BgJ5B6+Vyov9a8KyZYUBtp5GgKl71NY8sJ1KJeuKzNU7nkBjLMDNbeKuowAQbNP9CLsTB7NcBpioN65Gvg+9mqisxAOEWtLqKDRrOJHOW2447EEGLqZxF4rh9GMdw7PTIAVVAe3I94eaALYQn67XTiKC9X0iQXrFJPIho5Wed1IMKQASO8YL+T9ttosWLUF5ma79Uvp6VN9Y07HmLAtsC8G9O1auPe7/6qACajOSrhty5lT3+ous6owAwJcYdUG2sGxWfKvYYkGAoTz/cClDUDrqUfBFId7UpjNizi5Q+L0w5ECmiLyM0RKRkuXQesUbJ8hkHuIuTwjCUY7QRWqjGqQEPJWZKhuwETo24W4cf/RiBmbeBA0bmLXcwCOcNWXCefrAMU+RWTwFKKvLG7ZXMmf1Zdao6+7TNcYCNt6J7GYxeGLi1VkGUwr2T3DmHzU5JEhU6W7DGjWo4EuKvu45M8877unT2iuF8zY+o76q0B8W4TtHxKtoBIHSOW8/TdMCmM09lKP9eAe9SMvlzc8ejQl5jiZWRkB5cHM4iTWqCS BC+2Uk5T IHSaLvAwQAZH0ewzB6lWxDdmbnwcQOm+T7jEtIftpmOcqOSkSRMpCAPRmiuV8pd/NUAbw2MnJdiFRnYb4WYWavCZ9qUEYLnCh1CpzyMS0K4dR4uz6iSVu9VwoRNQOKXqdAadLrGzN2XSjF/eBeZNc7zNGgU/5rj6XA+CmJ3PR+TZ5RZwZL/PMfItdHIwqup6u41Ra6QBH2+/3Uqaz0TWA1FYtwfGVL/Ytdul0Xa1Foqxm7VuYkfdCzmkbPVFPv1ZPMnfpZ0+j1M8SNQGiIZevb4gF92WHmylbp8edI1O209S7KPUDCBhKQv//US380uGrrP5aNdYaAgpsvlun0Y7n0IKYelgFCbXFFbFUYZ8biO2D3oE= 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 10/8/24 13:52, Zi Yan wrote: > On 8 Oct 2024, at 4:26, David Hildenbrand wrote: > >> >> I remember we discussed that in the past and that we do *not* want to sprinkle these CONFIG_INIT_ON_ALLOC_DEFAULT_ON checks all over the kernel. >> >> Ideally, we'd use GFP_ZERO and have the buddy just do that for us? There is the slight chance that we zero-out when we're not going to use the allocated folio, but ... that can happen either way even with the current code? > > I agree that putting CONFIG_INIT_ON_ALLOC_DEFAULT_ON here is not ideal, but Create some nice inline wrapper for the test and it will look less ugly? :) > folio_zero_user() uses vmf->address to improve cache performance by changing > subpage clearing order. See commit c79b57e462b5 ("mm: hugetlb: clear target > sub-page last when clearing huge page”). If we use GFP_ZERO, we lose this > optimization. To keep it, vmf->address will need to be passed to allocation > code. Maybe that is acceptable? I'd rather not change the page allocation code for this... > Best Regards, > Yan, Zi