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 93230EE57DF for ; Mon, 11 Sep 2023 12:24:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0876D6B0289; Mon, 11 Sep 2023 08:24:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0336C6B028A; Mon, 11 Sep 2023 08:24:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E65346B028B; Mon, 11 Sep 2023 08:24:11 -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 D9DBD6B0289 for ; Mon, 11 Sep 2023 08:24:11 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id A7D72B33EE for ; Mon, 11 Sep 2023 12:24:11 +0000 (UTC) X-FDA: 81224233902.11.26B7A1B Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf07.hostedemail.com (Postfix) with ESMTP id D3FB94000E for ; Mon, 11 Sep 2023 12:24:09 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b="pPnVO/lZ"; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf07.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1694435050; a=rsa-sha256; cv=none; b=8FFnRJiNyTaUX4NjtyIHgCjBvRyQY86PlSy/jFQEVC2y6DBbwQu8w3vN1+QOFl/ZXl/RMj JWEpsk+sxkDLadGZfSHPXhiy1Bn6g2qqAOwc51gtWGkkmCXwmhq7bafcwgcHFi6ulOqZGw 3ph1MjYlILYRmTDDIaeGgfj7Brmj/Ws= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b="pPnVO/lZ"; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf07.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1694435050; 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=YjRjylMkvo2iz067JP+nGaOoVALTdbSG3qs/RtYsLlo=; b=ZGQUQXGP7N7+jOQTqj+nxrQbXVEb1NMZZvzs3rSQPM8mQCzZKGb3w2UVWMpB9j/UR5OC9k 8QPYuVPQkP4nJxvWaCN83sAs6+lgnSnV4DRpe7n1D2/2c1JOp6Nx1Tq+/dTmJCd1PulNVQ H2bCjDEvKjG1K2yFsJ4ogRX4QEYvKMQ= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id D4AF0211C3; Mon, 11 Sep 2023 12:24:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1694435047; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=YjRjylMkvo2iz067JP+nGaOoVALTdbSG3qs/RtYsLlo=; b=pPnVO/lZhHyOgr3kkrCIfsS59Zl+YuAiqFA6RiZseEljHgZPc/7bEwjgPlOGSNAyCtrlAf 1duEIVHzp28tt3DRE71iBxNhzyl9z+v8kAz+9917rSIPN4OalXtsIhxSxkTYG0ULjnIIRp afd5mO3oP0+QWRmsyBeC4dz2DLPAv7E= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id B530C139CC; Mon, 11 Sep 2023 12:24:07 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id N4tFKecG/2QuCQAAMHmgww (envelope-from ); Mon, 11 Sep 2023 12:24:07 +0000 Date: Mon, 11 Sep 2023 14:24:06 +0200 From: Michal Hocko To: "zhaoyang.huang" Cc: Andrew Morton , Matthew Wilcox , 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-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: D3FB94000E X-Stat-Signature: 6xu137wn7tjwacjsmptjuduwxkoca9qh X-HE-Tag: 1694435049-112097 X-HE-Meta: U2FsdGVkX1+qwl9nNhtCvqhFPo5DfcqGy81NvN7NPjSFcyQ+kwh0n52zwo0IJyaXKUNKlERtpvMlM1QAIBJ5r7YLn9oN9oyCyFwdULTJ0AQ92Ix+rEgaUCQldyj2HvZVEc5RunOmFR+J419tAwhL+TROq3Nzez8qHcYerrV7GWWhxwzQYwluv/pXnm84FGTAuKWVPgirvgtSA70A7oKX/64RhM4JuCm5fB6P6OpOxA5Fsu1PlbuQWnYvbLXkaXRzt2cse2ET+bpM/9pKPXBZoQxqkvfFgY1BDyKBgf7soqBFVIVejIiixHF99os/a0gCHDdjnPtIBjFt3A5IuqVpyr80MviB5C9dyAQ+9jEHRrUtfnnOaZ76+0+9rdalQcT/7jr08i3aZYnUujiegKTatwmT5vqTtR/Nc7Q+x96FVgULJuQT8tvYc2MjrFVdMx0l17yM0XWXVFYNVNjdPvAmD8M8/8+bBc0pQBNYoVql+Rb/ESJWBQiztRv4K8yeQn2eEk6re/t4i/URGBsH4pXjVfoqfyKIpBGlZsnlas94VVpsmKicKrIl6MF3BuGOVfpJQthFhhjtm1I9lykSY4knND4Vm8HgBu1jQ8cza+R8ccS0rF67HhRZAJEGjloqGAbTU4JwQQDzN+4jVvBAxpEWFnmThogkVZkNL9l7nLwgkzeyxS2k55yXvYRYy8TyZgHjtQMDj2HUBpCssAtmKSDGKEwKGlD98vOmWvoBnZTi3/VdiA9PXN7Z/A97Oi4/Qco513xt0hKT3A8xsrWA6pUxX1SH9hYR2B7uH4NoE5ADDC3n5h1Md2SxerMnaCoXOSffUbyDNgAmR9mQNrZKrwelQsf5Be/6dIquVI0CgH8JJt2OtR+3g+NxIzDtyGmhx3SDDSUFFJEZ6nLU0ZFaCfkhn8W8CtoBfWfoHHptt6Nnule6cdXlVicg1PAH8qgMjQ+EHzZGTwGRKPkxeQ9RQGP Hc8keya+ kwSRJXmQbV1/uYYPjO+gz3KkB4bOkpEHVtp7VuUifXIca3CiLC1xdOEgW/imnll5ns9RSJDWhrHo4g6bj+uraR2X8Sj7Yc9nE6/vY/5lcDXsKL9c+trpBwxvaTzmo+42Q1BjztkbaQ+KFvmHRskUEKYe+YinBR0BOHsDJFxvOHnzJ5wi4NHXSkxga3MxyTwlORoUmhp+WwoZr9P3c8DEx4oFUaAdbBHjzDTNA7/eE8na8nABNPELDi+TZs3AO71pwseg/ 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 11-09-23 14:12:26, 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. > > I would rephrase as follows: > Many architectures (alpha, arm64, ia64, m68k s390, x86) define their own > vma_alloc_zeroed_movable_folio implementations which use __GFP_ZERO for > the page allocation. > > Those which rely on the default implementation, however, would currently > go through the initialization twice (oce in the page allocator and > second in vma_alloc_zeroed_movable_folio) if init_on_alloc is enabled > though. Fix this by checking want_init_on_alloc before calling > clear_user_highpage. Btw. have you checked other places which could have a similar problem? >From a very quick look __do_huge_pmd_anonymous_page, hugetlb_no_page, hugetlbfs_fallocate and shmem_mfill_atomic_pte all follow the same pattern. They do allocate memory so they go through the initialization in the allocator and then reinitialized. -- Michal Hocko SUSE Labs