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 63E04C77B6E for ; Fri, 14 Apr 2023 15:07:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EF22F900003; Fri, 14 Apr 2023 11:07:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E7B07900002; Fri, 14 Apr 2023 11:07:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D1BC6900003; Fri, 14 Apr 2023 11:07:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id BEA5D900002 for ; Fri, 14 Apr 2023 11:07:58 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 7EC524036E for ; Fri, 14 Apr 2023 15:07:58 +0000 (UTC) X-FDA: 80680326636.18.CA8F8C3 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf12.hostedemail.com (Postfix) with ESMTP id 6066440011 for ; Fri, 14 Apr 2023 15:07:56 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=o8vMFzsE; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=of02Ek1J; spf=pass (imf12.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.28 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=1681484876; 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=3Lw5y1Ohxl8cFOKOdx2RWPNSRtZicRkZCTHDZWK77uU=; b=svQEtrJOlcz1giqMcBaowK052rS8MwcXXmj+xI+QDDyA6k6JKrYQnqLFxwIIkYlizeUwqH CkJzt87xVuqfileOyvh4tEunvrpUfMPknZowW+/68tQknf0edbpT2A+4u4J2Zcp+11v/4D C6GwNYUCRUzEt27GnaJooZIBw3xbH0c= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=o8vMFzsE; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=of02Ek1J; spf=pass (imf12.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.28 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1681484876; a=rsa-sha256; cv=none; b=68j+xBa4tVLamJcWdIu+Ha7P7aZEoebpeqIHmLWB40ggOCN71Lao4ffZfGRkz3CGLDan6D 5SkXbUeavb0w3G3wtNe9BR2Ko/lVEKwkzcgQ5908goUhJuwC+FwHB9Hf6hMtY4r7BOowwT AS+aiZ7naj0j6Reqvk40WOX3AGf19JM= 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 DE28F21998; Fri, 14 Apr 2023 15:07:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1681484874; 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=3Lw5y1Ohxl8cFOKOdx2RWPNSRtZicRkZCTHDZWK77uU=; b=o8vMFzsEPCV7DCQt5MNgSxAAUXr71RTdqNu/MeD37uT/vT3olPz52ihUC4exsz5KBaRfns qRJA4LrZBCZ05OdOpeDHRGNHszrTF84/Mct+aswdSFPHlAyV/Q4JFZEIzbw1u8RkilA/8o eHXnei60MwV6BGV8H5m15L7CgZJoZTM= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1681484874; 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=3Lw5y1Ohxl8cFOKOdx2RWPNSRtZicRkZCTHDZWK77uU=; b=of02Ek1JjsWzbfTiGtOaWzLZm8ptdB760P+Cy5XudoZmaZKv4l8fWZl6PffmCg3Bmv530s vDfHfvbVewu0lgCA== 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 BDADA13498; Fri, 14 Apr 2023 15:07:54 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id Q7eMLUpsOWS9OgAAMHmgww (envelope-from ); Fri, 14 Apr 2023 15:07:54 +0000 Message-ID: Date: Fri, 14 Apr 2023 17:07:54 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: [PATCH] mm/page_alloc: consider pfn holes after pfn_valid() in __pageblock_pfn_to_page() Content-Language: en-US To: Baolin Wang , David Hildenbrand , akpm@linux-foundation.org Cc: mgorman@techsingularity.net, mhocko@suse.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <62e231a8f2e50c04dcadc7a0cfaa6dea5ce1ec05.1681296022.git.baolin.wang@linux.alibaba.com> <94bfa3cc-674e-25b0-e7e2-d74c970acef7@redhat.com> From: Vlastimil Babka In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 6066440011 X-Stat-Signature: 1mro65pws69i6w46wbyd9sqafn87adpj X-HE-Tag: 1681484876-748969 X-HE-Meta: U2FsdGVkX1+5wcOAPLxkkLFFVFIw5169g58uoD0S1loHckhMxbRX5F9NOysL0jEbozu/AbV3eW8f2xM0FCFCZWnhSIs62JQvVxEX7/9MKnZxuxhS7XzvEjvC45qEutmfexk/SL8manreAym69xO0RkOymmzKnsgVlnfA4atYfxtM75ExzJKf+hd5rRTVR2rYhGb1sseWf7lTH6kui3ESdF/3PjZfkH+OuRlM5B9Z6UneYZxGVe00qY0fyUmyzDR9dR5ivUOR6nF8LKl2HjnW0anLx1zt917Tn3HEuTe/cicb7iuDki7VsTEbyVyeLeRG83HA7dJTz6xi1AMApHIyy7mXd+ORUpXtzD7uiiDeiEFIbpVUnXrLVj5WS30X4bl5sYgcX/oBzjnEYnQCOcDGL3u9rBv4B0HtfkAF4Mt3wyGROs7ckB/8EOg+prTLCS60i3h+aJ4hmodhPf1Mvn5aW9ihO7CKfCVkc0pt7MxhdZpxckvxwzsVeX2K0ghaW9+bNU/tK5UTelMH1xSfc3LPIHkkwRAD33zcQnzJPTZd/s8e4f5wPGCad3Q0GxAd3DjCNSUG7Ezujx4iD8kPnkX8myGLbKoYSf9HB4MvPXxAoSmcRJCx9YcLX6SnpJzL3il2ida9Kqcz7+EwleBPPLJ7meEDjBSK8GA7JZvvxMbKccTSqPeXZzVCA2a38m4hurMzGuD7qWT9s9+XBrgPFy4Fnj6OVVl/oXt0V95iymlA8GvyefvF6MNUo7cWCrHym6rfnLUPG15wMHJ7uhmaREr2XX+z+iuKEWQIKBQP3sC9ZpczHphaAwrO0FFyYNWaCsvwur5WsucmXJkOhXpxarn7aT1xgxHxl9D04wu4hE3xUIyyguo6Bk1AapyM1yX4q+0nnbOU3dn1UC6TGhwqON1r5foRbt9QcRqkzPEPpQyN6DJUgae+MrXcv0MA0a+b0LqLIoOqk75DQRJMyi6sh0I 98+BBg2/ 9otOBoUAZ4NA9CwO31oDl9JBvPEZL6F506mcoFrCoTgFgDYGV+dri5448u9HCL2rWAmNyAVynAnKanoVkUAeffYoeRQ80UGE+PAqqDGILoRZmfGuK4yiJLo9htHLhmkKIhpVhNuXJ6yzPITv0R7Nyj+oAAeaXgC5ZnMuSxKFWv5DLk5gFvyoSzpLKN4BlEVxv4/xBuFdvn9rzcvqntnI5kXCCwIzI9n+TvZgXejsWtNncc/W9Y3tiRIiVRCyj6c+aqJd7 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 4/12/23 14:16, Baolin Wang wrote: > > > On 4/12/2023 7:25 PM, David Hildenbrand wrote: >> On 12.04.23 12:45, Baolin Wang wrote: >>> Now the __pageblock_pfn_to_page() is used by set_zone_contiguous(), >>> which checks whether the given zone contains holes, and uses pfn_valid() >>> to check if the end pfn is valid. However pfn_valid() can not make sure >>> the end pfn is not a hole if the size of a pageblock is larger than the >>> size of a sub-mem_section, since the struct page getting by pfn_to_page() >>> may represent a hole or an unusable page frame, which may cause incorrect >>> zone contiguous is set. >>> >>> Though another user of pageblock_pfn_to_page() in compaction seems work >>> well now, it is better to avoid scanning or touching these offline pfns. >>> So like commit 2d070eab2e82 ("mm: consider zone which is not fully >>> populated to have holes"), we should also use pfn_to_online_page() for >>> the end pfn to make sure it is a valid pfn with usable page frame. >>> Meanwhile the pfn_valid() for end pfn can be dropped now. >>> >>> Moreover we've already used pfn_to_online_page() for start pfn to make >>> sure it is online and valid, so the pfn_valid() for the start pfn is >>> unnecessary, drop it. >> >> pageblocks are supposed to fall into a single memory section, so in mos > cases, if the start is online, so is the end. > > Yes, the granularity of memory hotplug is a mem_section. > > However, suppose the pageblock order is MAX_ORDER-1, and the size of a > sub-section is 2M, that means a pageblock will fall into 2 sub > mem-section, and if there is a hole in the zone, that means the 2nd sub > mem-section can be invalid without setting subsection_map bitmap. Can that really happen? I think the buddy merging in __free_one_page() would trip on that?