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 C66FBEE7FF4 for ; Mon, 11 Sep 2023 12:47:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 489A06B0287; Mon, 11 Sep 2023 08:47:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4399A6B0288; Mon, 11 Sep 2023 08:47:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 34FCE6B028D; Mon, 11 Sep 2023 08:47:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 215EA6B0287 for ; Mon, 11 Sep 2023 08:47:18 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id EECE6A0A3B for ; Mon, 11 Sep 2023 12:47:17 +0000 (UTC) X-FDA: 81224292114.01.F5393E6 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf15.hostedemail.com (Postfix) with ESMTP id 30421A0037 for ; Mon, 11 Sep 2023 12:47:13 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=GAGPBrS4; dmarc=none; spf=none (imf15.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1694436435; 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=AT/HwmSFNvPgul/c1kKp5PbdGjEUzpII4wStP5rXfVI=; b=RNCM7TLX4ZN5tyrQmr7+77N0SaRZxccIaFG3vlQWRMCKOzHJK5xeloI30o1yY0QVnae1iR E3VqFv6gJL/8tZcBGuhdTtQt5GsH08L/R565xAkN6PRC1Dg0aMMCMKB5FaVHpy6BGR9f0G n09Z2MGj+v2Uhzpv7t0pRkEzAafIr4A= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=GAGPBrS4; dmarc=none; spf=none (imf15.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1694436435; a=rsa-sha256; cv=none; b=n+1eX8r/0t1RlJx0Tmt2/Wv96ys4/Gf9DIRQSkV8QzfvXMIKrCnccjHqf+ArBd7Y5uxgCu 56ACG31flO6pi0jfBiURF4lo1Z74Sropimt4aDYIkoApfPjHHVOQ/YDjyvNleVJe4qBRXL mzHDtIWe6EvNWdnAv/ChKy1HM6F0Q2I= 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=AT/HwmSFNvPgul/c1kKp5PbdGjEUzpII4wStP5rXfVI=; b=GAGPBrS4O64uc1P1Dkt0dT5nbd wkftLVuzMLe1jQYqNe1N5/9Cs96OcwNv/MClUqUZ91ZRefOLLHW2HbHfd0oQKpWwbTDl1vC3ZJ3PY f1shLDG53/7qYiki3xfy5Yg1KsPVFOZWrTklRGEjq7FV01u/3rWvmfYipKn22+fiXUUPkVQ3P0/UD ywAyX66FLyzCCCs2349Z4YQdi+T1EojvXQkxelwPYxxCYretVYjxO3Ai5Gz+SzMssFYkheGfW0I7l xv8+AFC++Pj0xJIGNdWwpKvuXaA7oQUD7LUaFppzv91Oqxf1qhfILlJUBIqG9Lo7Zt4q4ecnrebZH ywR7pbpg==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1qfgJj-0010FI-FL; Mon, 11 Sep 2023 12:47:03 +0000 Date: Mon, 11 Sep 2023 13:47:03 +0100 From: Matthew Wilcox To: Michal Hocko Cc: "zhaoyang.huang" , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Zhaoyang Huang , ke.wang@unisoc.com Subject: Re: [PATCH] mm: remove redundant clear page when CONFIG_INIT_ON_ALLOC_DEFAULT_ON configured Message-ID: References: <20230911104906.2058503-1-zhaoyang.huang@unisoc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 30421A0037 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: iwr7m966whhoqmy5zkty9h65ejh4hoqq X-HE-Tag: 1694436433-870083 X-HE-Meta: U2FsdGVkX19KTBBcsAmyndBWaIzejx/MYEqcKEU/KUL9bdEKICuoZlfzcOwQCwd35s+kBp/y4OP7kH6OYx3Qr3fTQBNEbAWqJiQWGJkjcYtsL9bh1AmVAzpaySTQHUdlsH2fZqXpaDI8GJAK2Dw62vFUMwZ7zvyVpQoRynXCmIUt9XSgIJlAqSRaXGht1gCe87vFD086EFjXccuxig0spZJcsmz5tlr5Af1pumBZShZvWSJzUtP49GkBbifZdHMPxjosjflPViwnRlb7KYLNTmCpNdmlLfHlAUCIype/ykwaGbAJ6dEXf4ledSRJTshTaBlMrZrIfEE0OijRAeNUJHUhnQAyvFOZNYCtT+yyBFOfbrciKFfVuqEUOsP638VZoW0RLJk+kb9Bgf84HUn2X0y5LipHIgYxpaT1CfjZ9OPnAgiUroSWz17yObETP0+GW95OoTigAKJnI6k0x7WZQTylcOVt+SfwTeWZRMIvZRfXF1qXj/rMzZmlyUNd6CWUzsXEQ4L3ztBoHp0WhgQ1HXoprjWaiMvlesHSC7psi2mU5aslet0KIHrC0vIjWNqv38/EHdpX0OC91kssYDg0q/VA49dI1wWazuEsAC5Kvm+6Uv+T147WZ+6Qr7WF3IFA9SgAxr5YS/cckiSAhtVFu7mBzq8TNux6kV4rV33kF9nU7Zrb7rVgfeDDGS7YutowSW5Qp+guZrNyWlLh0XP0dG5EOnw6J9veN5y0CuXU3D7UaMTQyQ8ZKORMG9PpCc/kT1lr7GZ7uSpxKMVtNCKpbmOAov6LwqFhshrne0JzsFU7rVLQH2Sc9xRRGyoN4hZ3JA/h6AvCO5qygjIPSgT46U8H8R53DeUWPTaxlF3krreWC4HG4BFbJvOl20rgRxLbp565ZfIbL1wtO/eII5tTqIUd3l5Oi/bD58c1qeZ2Qq+MmY7tGP1p5VGI+eSuavFWILSeQHqchS5Q0WG5D5m 0KoT2q0I m1yNk4SCGqv8dPbY9aaiTZy/t0xqtZ06EZtDZ90njqoO+ItE8tO2BL0ZSbSfKWIAkdZM0OtaPGwguaC/LBI+T8yoM8r65zMR8uz2ipWb90sZuNZTiS6aXKLJkah44hJQt4L978ukH0UySeDHgxEXWzCDpI2TFWRmQtjb6YAKNFLn6Kz7hrOV2v0mphkGDAQV/PCMq2S4DbRySPneTbzIKHj6Q+VCKqurEIQ+CYrYfquR6td3mulrFogiL/w== 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 Mon, Sep 11, 2023 at 02:12:25PM +0200, Michal Hocko wrote: > On Mon 11-09-23 18:49:06, zhaoyang.huang wrote: > > From: Zhaoyang Huang > > > > There will be redundant clear page within vma_alloc_zeroed_movable_folio > > when CONFIG_INIT_ON_ALLOC_DEFAULT_ON is on. Remove it by judging related > > configs. > > Thanks for spotting this. I suspect this is a fix based on a code review > rather than a real performance issue, right? It is always good to > mention that. From a very quick look it seems that many architectures > just definte vma_alloc_zeroed_movable_folio to use __GFP_ZERO so they > are not affected by this. This means that only a subset of architectures > are really affected. This is an important information as well. > Finally I think it would be more appropriate to mention that the double > initialization is done when init_on_alloc is enabled rather than > referring to the above config option which only controls whether the > functionality is enabled by default. This may well be an unsaafe change to make. We're not just zeroing the page, we're calling clear_user_highpage() which tells the architecture which virtual address the page will be mapped at. It could be that skipping the zeroing ("because the page is already zero") isn't enough; there will be traces of the former contents of some page in the D-cache for this address. Or it might just be an optimisation. The description of clear_user_page() isn't entirely clear; the port may be relying on clear_user_page() to have flushed the dcache aliases. At this point, I don't think this patch is worth the risk. My mind is changable on this, but I think we'd need buy-in from ARM, SH and Xtensa (who directly define clear_user_highpage()) as well as Arc, csky, ia64, m68k, mips, nios2, parisc, powerpc, sparc who all seem to have non-trivial clear_user_page() implementations.