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 3565FC7EE23 for ; Mon, 12 Jun 2023 06:40:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2CB308E0002; Mon, 12 Jun 2023 02:40:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 22C446B0074; Mon, 12 Jun 2023 02:40:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0F4AD8E0002; Mon, 12 Jun 2023 02:40:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id F34406B0072 for ; Mon, 12 Jun 2023 02:40:27 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id B149580132 for ; Mon, 12 Jun 2023 06:40:27 +0000 (UTC) X-FDA: 80893146894.12.E504CE9 Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by imf27.hostedemail.com (Postfix) with ESMTP id 50DA14000E for ; Mon, 12 Jun 2023 06:40:23 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=Fzhrsw44; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf27.hostedemail.com: domain of ying.huang@intel.com designates 134.134.136.100 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1686552025; 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=ayPyLvaknN3EOfmCiBHjGkE9PFqIRXDuRbGCOkHVssk=; b=jF1OIH/bpVJ0gENnokwaYcrtEJu53Z+v90r2ktBEqrwVHgZKNcltRo9CMqwSkVWk2kergB kwMHFDIhPvrnl3/gf/VjiKGD+WiY93QsETgfeMU9QsUhCAth49LCQhNiU1nEuLG6RoSsL0 jWe3VLYeWXhzecwskgYfV2uD9EQGAGU= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=Fzhrsw44; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf27.hostedemail.com: domain of ying.huang@intel.com designates 134.134.136.100 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1686552025; a=rsa-sha256; cv=none; b=pm5rpMd6VkrIU6KNE0qbUUGm6YoIibmR0DbGtmBKxgQp0UxrKSFJdwh+g0l0/mkJPQTfaC d9aLoywJwVvmVMlwp/wBK8vhLYszrZbKjs5jyYqG3azBHiE4N218MLZ3GG0sgOCAzvBg6S +W1ImlL97OYImovXyo12X/XFjbg9xDw= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1686552024; x=1718088024; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version; bh=SAQMgb3bEhPtdx+c6WuJkLQHwIW8d3NCrLoMI96JZRU=; b=Fzhrsw44RtSrabXjq680HRpEv+9V8Yc8eXeLv2PR4qP7Rn2/W0Pmz/d7 60o9+JZgbwGObCodyCv19fy63X8cuYLE1OfiHt6r9QU++jhOfdK4djFPT /KdPJlYvyAPqv0H0CtLef/fN8jpYujfv3I3vOvZwzrbcrM72Lu8O3HSm6 SVTWvdK2aIese8iwIRlqOeh3dafdP7SurJBxdvozqsyxlA1Xm63aXpnT6 4hRhoriTiTLP1xqnKkM6hkR62O8e2BzI7YY8afkpdn64Jj8SuLT7aqA6c IXUYfyUDG9s80DR+q1IqSA1owr6LYbQcURp2hUzXmpdrE7rDfjBR4DBng w==; X-IronPort-AV: E=McAfee;i="6600,9927,10738"; a="423839311" X-IronPort-AV: E=Sophos;i="6.00,236,1681196400"; d="scan'208";a="423839311" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Jun 2023 23:40:13 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10738"; a="776234058" X-IronPort-AV: E=Sophos;i="6.00,236,1681196400"; d="scan'208";a="776234058" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Jun 2023 23:40:11 -0700 From: "Huang, Ying" To: Baolin Wang Cc: akpm@linux-foundation.org, mgorman@techsingularity.net, vbabka@suse.cz, david@redhat.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm: compaction: skip memory hole rapidly when isolating migratable pages References: <8cc668b77c8eb2fa78058b3d81386ebed9c5a9cd.1686294549.git.baolin.wang@linux.alibaba.com> Date: Mon, 12 Jun 2023 14:39:03 +0800 In-Reply-To: <8cc668b77c8eb2fa78058b3d81386ebed9c5a9cd.1686294549.git.baolin.wang@linux.alibaba.com> (Baolin Wang's message of "Fri, 9 Jun 2023 17:45:54 +0800") Message-ID: <87sfax6v7c.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii X-Rspamd-Queue-Id: 50DA14000E X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: gftfqd1h4udkx4qf1w1hkz9p5c5gfic4 X-HE-Tag: 1686552023-505917 X-HE-Meta: U2FsdGVkX1+wT6Hiqa+G+rwjJcm+HfqoH2JNaD1uD9DkSCduWl09zuvHhZ3B1BKmleVsqpBJh0fn6Ilwdwy3qzd+U2KbFnqjnEclQOgHnF+s5M9e+PPhGKfq+0/xhthTwkSJL/rHpcdIHWMS6ggb9ijhAzJZtgZQEO0UjK9/nIVHZKGirIU2YXlPWN1ke9R81gHgr0MNAjws6SRFZAJi2RV8+VvWynnOKDhlkfo5ZOuWovBN7murqkS54+WZEb3UEtQkdZ2vTXxzM+++NrRvW+TSPax9lkqehMVMt5BkgBGGtvbXjauURt/8RemxPuLJfAfR8OdReDY2OFOIvrTCnYLKkM4OpVihawEVOB7iXY7PXArZyadUAd5CjHwOslRfKY8CLafOxYwnaIw+WUUWTW3D4pjKIaQQsvqWl5xPovzLBjhenCOzPKx0/0tGFgNaOOadO2FaLiq30CaSQHID53u/J78BV4Js0bimXjWJyKF5IwRLWdfGxd+47JgnBYPOaHT/it8sGM7QL/uc4o1dSocs6Hq6RNXHm/jmldDsswgKTNcdcPKNnvJJt7gk1GqjCEUE9DXpsjptnU6j7R0eCogMbA5/jBFZhckV2SMnzRbWWi1RJVLElDrLvLSDpAkFu7wsG3MsKyPdchzYKtEqZDk0e/o1tzB9XYZsuGOEaU5oUwhZMudUj9zrBS8a9umYVfdJT9cpdf2g8e53mH2S37vKxJEQgLwBQMqINohqmZk2URY3qSO743XQlqoQKTX1ouwvoTa2eqeP10d895NMtl42xUda2SQ0tdMcfvkFjxmO0B9J//8zeLtfDNjYqV0YF/pFd4dPCkNGWJKSSuXZFrc9TLmezuw0mD8W4g4BsmLOgnOWx9AvfSo6N3I13wZN+uC9LwpYZgRcE909+KKWd0NtwHem42+4tDXjBuwwRy/NY49f5RqMah/7ivYd5f83w9xQLp/5yH3Qyp1iIfn hDAmcydh GedjlL2AJG+xHmFPs50NTqEbNSihh882fwfcrTvYVQ9MJe9qVSZjurRAmq46j3EPtyoy9vz0/LkrUw8ker2ThFX82dNWYbs7OgnUPakHMy1YrPsAYqvRnD7Sqr8B3+CjgxzYOSFFK552f+CQSkAhUSWeTnG8neYHlfUh3wj0W4fxsS4AgvJhO5/DbY32bgEW/EHSWemd4gcWI55FFzKYfYHqsSecQ4QUPKqhBB8wEOjWDq+oslfrwcdUAJql+YWE0MjOG 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: Baolin Wang writes: > On some machines, the normal zone can have a large memory hole like > below memory layout, and we can see the range from 0x100000000 to > 0x1800000000 is a hole. So when isolating some migratable pages, the > scanner can meet the hole and it will take more time to skip the large > hole. From my measurement, I can see the isolation scanner will take > 80us ~ 100us to skip the large hole [0x100000000 - 0x1800000000]. > > So adding a new helper to fast search next online memory section > to skip the large hole can help to find next suitable pageblock > efficiently. With this patch, I can see the large hole scanning only > takes < 1us. > > [ 0.000000] Zone ranges: > [ 0.000000] DMA [mem 0x0000000040000000-0x00000000ffffffff] > [ 0.000000] DMA32 empty > [ 0.000000] Normal [mem 0x0000000100000000-0x0000001fa7ffffff] > [ 0.000000] Movable zone start for each node > [ 0.000000] Early memory node ranges > [ 0.000000] node 0: [mem 0x0000000040000000-0x0000000fffffffff] > [ 0.000000] node 0: [mem 0x0000001800000000-0x0000001fa3c7ffff] > [ 0.000000] node 0: [mem 0x0000001fa3c80000-0x0000001fa3ffffff] > [ 0.000000] node 0: [mem 0x0000001fa4000000-0x0000001fa402ffff] > [ 0.000000] node 0: [mem 0x0000001fa4030000-0x0000001fa40effff] > [ 0.000000] node 0: [mem 0x0000001fa40f0000-0x0000001fa73cffff] > [ 0.000000] node 0: [mem 0x0000001fa73d0000-0x0000001fa745ffff] > [ 0.000000] node 0: [mem 0x0000001fa7460000-0x0000001fa746ffff] > [ 0.000000] node 0: [mem 0x0000001fa7470000-0x0000001fa758ffff] > [ 0.000000] node 0: [mem 0x0000001fa7590000-0x0000001fa7ffffff] > > Signed-off-by: Baolin Wang > --- > include/linux/mmzone.h | 10 ++++++++++ > mm/compaction.c | 23 ++++++++++++++++++++++- > 2 files changed, 32 insertions(+), 1 deletion(-) > > diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h > index 5a7ada0413da..87e6c535d895 100644 > --- a/include/linux/mmzone.h > +++ b/include/linux/mmzone.h > @@ -2000,6 +2000,16 @@ static inline unsigned long next_present_section_nr(unsigned long section_nr) > return -1; > } > > +static inline unsigned long next_online_section_nr(unsigned long section_nr) > +{ > + while (++section_nr <= __highest_present_section_nr) { > + if (online_section_nr(section_nr)) > + return section_nr; > + } > + > + return -1UL; > +} > + > /* > * These are _only_ used during initialisation, therefore they > * can use __initdata ... They could have names to indicate > diff --git a/mm/compaction.c b/mm/compaction.c > index 3398ef3a55fe..3a55fdd20c49 100644 > --- a/mm/compaction.c > +++ b/mm/compaction.c > @@ -229,6 +229,21 @@ static void reset_cached_positions(struct zone *zone) > pageblock_start_pfn(zone_end_pfn(zone) - 1); > } > > +static unsigned long skip_hole_pageblock(unsigned long start_pfn) > +{ > + unsigned long next_online_nr; > + unsigned long start_nr = pfn_to_section_nr(start_pfn); > + > + if (online_section_nr(start_nr)) > + return -1UL; Define a macro for the maigic "-1UL"? Which is used for multiple times in the patch. > + > + next_online_nr = next_online_section_nr(start_nr); > + if (next_online_nr != -1UL) > + return section_nr_to_pfn(next_online_nr); > + > + return -1UL; > +} > + > /* > * Compound pages of >= pageblock_order should consistently be skipped until > * released. It is always pointless to compact pages of such order (if they are > @@ -1991,8 +2006,14 @@ static isolate_migrate_t isolate_migratepages(struct compact_control *cc) > > page = pageblock_pfn_to_page(block_start_pfn, > block_end_pfn, cc->zone); > - if (!page) > + if (!page) { > + unsigned long next_pfn; > + > + next_pfn = skip_hole_pageblock(block_start_pfn); > + if (next_pfn != -1UL) > + block_end_pfn = next_pfn; > continue; > + } > > /* > * If isolation recently failed, do not retry. Only check the Do we need to do similar change in isolate_freepages()? Best Regards, Huang, Ying