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 5DA2BEB64D8 for ; Wed, 14 Jun 2023 01:10:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 87DF38E0002; Tue, 13 Jun 2023 21:10:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 82D3A6B0075; Tue, 13 Jun 2023 21:10:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6F46B8E0002; Tue, 13 Jun 2023 21:10:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 5D20C6B0074 for ; Tue, 13 Jun 2023 21:10:57 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 24EC0A0641 for ; Wed, 14 Jun 2023 01:10:57 +0000 (UTC) X-FDA: 80899574154.03.12A9A8F Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by imf08.hostedemail.com (Postfix) with ESMTP id 5C9CE160013 for ; Wed, 14 Jun 2023 01:10:54 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=dyMuDqoY; spf=pass (imf08.hostedemail.com: domain of ying.huang@intel.com designates 134.134.136.20 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1686705055; 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=KZd90+5afXlWrFzO5Jk+lT0Ft647dJAHp6ddx25s8H0=; b=mX5fj42NFAyuGiJa1pL3353mMxrsnrMMrAkTarCMV3e29xzlp8NxQqCadWRw0gprwD79oR 5nzSuUYSSQXJvlXGgMdYDbTyRqeg9kqAvrqsSy6PCiJ8CnxPk/tbd972bwTcYhFE7tAEs2 2GMo9JJsYfrEdR0U+wo4t5z3q7pDGiY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1686705055; a=rsa-sha256; cv=none; b=DCp+JfnG3N4L0fAyiswtkRgeahePolMV8AldbyEPNTgr8tdvvrR+fIcMo56etW4IHz3izn fnoGEDNNRS0LgoZAPbOblylnd/+ho/PyjC0ty6BxBNUUPca5dVjkwX5HJO3AnKZnj53pKT nfwFqr75XUgGQR0plc+N/GgqtvVrnlU= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=dyMuDqoY; spf=pass (imf08.hostedemail.com: domain of ying.huang@intel.com designates 134.134.136.20 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1686705054; x=1718241054; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version:content-transfer-encoding; bh=azG8hPwvF5L6fVTdJH7JGGkoqQA3l0SkJuzFaSDICuE=; b=dyMuDqoYNRslfEOgf50PxtLZszoNIPz/rX58ufoGrJKZyiYcJzFemKZZ 3Oli9ydAJ19+ylW7xuLr/3MSKllNzvK5M4wMO/Z14FADdcT+wTQeYMxJH sIwdz0/4SmGpGwGKEfUmhLfbUvZF7UPIqsGX/8lCCdVoQaCgZPIQkHrJr HZH9vpqpKOnAcbGBThuni/pTErOYjOilHjskaIMQbNnRkD7cwKL9m/PUC oPiRhQvvMK7p1bZlqj9hDYQxSP/igUr+JOehFdgphEFc7telJTq7NzD03 hYcK82to5DjBuZAi2qfd8lTDwRLDqwwJ7/8evA+WG7JKLOFwgp2SvrjJC w==; X-IronPort-AV: E=McAfee;i="6600,9927,10740"; a="348146738" X-IronPort-AV: E=Sophos;i="6.00,241,1681196400"; d="scan'208";a="348146738" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Jun 2023 18:10:36 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10740"; a="744890461" X-IronPort-AV: E=Sophos;i="6.00,241,1681196400"; d="scan'208";a="744890461" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Jun 2023 18:10:33 -0700 From: "Huang, Ying" To: Baolin Wang Cc: David Hildenbrand , akpm@linux-foundation.org, mgorman@techsingularity.net, vbabka@suse.cz, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] mm: compaction: skip memory hole rapidly when isolating migratable pages References: <770f9f61472b24b6bc89adbd71a77d9cf62bb54f.1686646361.git.baolin.wang@linux.alibaba.com> <838c3066-43e9-2035-cf69-4957481cddda@linux.alibaba.com> <77b2ffeb-732c-229e-0f41-f63f75e43164@redhat.com> Date: Wed, 14 Jun 2023 09:08:55 +0800 In-Reply-To: <77b2ffeb-732c-229e-0f41-f63f75e43164@redhat.com> (David Hildenbrand's message of "Tue, 13 Jun 2023 14:36:33 +0200") Message-ID: <87wn06j1eg.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 5C9CE160013 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: hqnpwciabazturkhog6zi3rmju3tf8zg X-HE-Tag: 1686705054-807852 X-HE-Meta: U2FsdGVkX19q7JJmo6fMyMtk/jIT75sMnEc7yeKywGOubv+bHitCJ6DSB3puUpEMfpNF7TiIdI9y9ULHGDqBOGIoxCn3bH5bq1Y4I0A7yky28O9Dm6cFPVYW12dE3+B+s7A+H/F66R3i4siRtnSHdzKL5iZub0fZpLIUjHngF92ebHhWO2+4XyqAMMscQYgVkKcjxRPIe2SkqnlBpHDyabIAl4VsZtOcUiijAzQ81PS3kiz0mkwgab7jOrKSd+33tj+8EtwDXYtqHoX7Cvr21O+PNUlRTjaIBWs6SE7W2KGA/Zkx/yS0ttUQ4g2AbLefY5Z8ew5aCxWYB2UB59Ioimkkqw6I38Ql12R8O6fux4wtS7ZpXnUgrxjrHlNKSEgXaGo4Qnapuop7AzU/XwmusrafmeSbLe4t4csyvlsd+PPJ+S/YNDXOI5MQ+FASkKuRF6rIOz2DkWYLeA+q/KdvD20VUzXV2HKuoDM0KaaIZou84geUMHpMTA9PHr1/GRDlT9B39k7XcSKBEqNwfr9LzRatkLaGjUZp65tBkQkCdGgbVrVQn/IfCf8BWqZpOJYBErla0jSjOYUTayrvInErs/CPmuyousB0+8a9CVeiZUUUF4Yhy3ZnAifP+GalncTq4JDfrSefSXx54lP6o01DNC9S5BW2wPZdAfeBvRN69HV13uRvFsVNZD/ZM9jFDQho406NvK4XdqITkZ623376tf58Nj+S+szSeEo4wNHc4Q5416FgiiEHDkSw2wL4fIwm5IIT1GUlqTNHoIWtGgDTRMuvg3diOmTTFIuEXjygM5hj7HSbRfQ/v27e4+2sgwb+cWyKQtQjTQZ5N4VhaeprsE3AproDfSJ82zkoA3Hpm+hSToMkKyC7CQ4/7kwigaP2OKrK1GHGqgJiIr/EIgS8m6OlDYJHEon4T0NhKhS9QREBn5b85XT1C3YuOUxT47bBydOovw5aINYKmJTJZRD Yrxxkl+M GfxV3nPmfX4BqlUO7p0FAs1aIFtnDMm7jlGiX9Y27LVaC0UnY10bvhBSK1tndmqnilKWayVUmqLB3RU0aC4744cBm2+XAHHuREh7f67hf6TJ1aOB+dVqTnFNp9ogxCmzyIetlbY7ln8WygCAJDyNYteuHnJL6sMjwdlIHsxPBwQ5Ex1NWBhqR/FRVDYCjPQWCBhQkm1RoPNS3WQetIWTMcA6sWQ== 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: David Hildenbrand writes: > On 13.06.23 13:13, Baolin Wang wrote: >> On 6/13/2023 5:56 PM, David Hildenbrand wrote: >>> On 13.06.23 10:55, Baolin Wang wrote: >>>> 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. >>>> >>>> [=C2=A0=C2=A0=C2=A0 0.000000] Zone ranges: >>>> [=C2=A0=C2=A0=C2=A0 0.000000]=C2=A0=C2=A0 DMA=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 [mem 0x0000000040000000-0x00000000ffffffff] >>>> [=C2=A0=C2=A0=C2=A0 0.000000]=C2=A0=C2=A0 DMA32=C2=A0=C2=A0=C2=A0 empty >>>> [=C2=A0=C2=A0=C2=A0 0.000000]=C2=A0=C2=A0 Normal=C2=A0=C2=A0 [mem 0x00= 00000100000000-0x0000001fa7ffffff] >>>> [=C2=A0=C2=A0=C2=A0 0.000000] Movable zone start for each node >>>> [=C2=A0=C2=A0=C2=A0 0.000000] Early memory node ranges >>>> [=C2=A0=C2=A0=C2=A0 0.000000]=C2=A0=C2=A0 node=C2=A0=C2=A0 0: [mem 0x0= 000000040000000-0x0000000fffffffff] >>>> [=C2=A0=C2=A0=C2=A0 0.000000]=C2=A0=C2=A0 node=C2=A0=C2=A0 0: [mem 0x0= 000001800000000-0x0000001fa3c7ffff] >>>> [=C2=A0=C2=A0=C2=A0 0.000000]=C2=A0=C2=A0 node=C2=A0=C2=A0 0: [mem 0x0= 000001fa3c80000-0x0000001fa3ffffff] >>>> [=C2=A0=C2=A0=C2=A0 0.000000]=C2=A0=C2=A0 node=C2=A0=C2=A0 0: [mem 0x0= 000001fa4000000-0x0000001fa402ffff] >>>> [=C2=A0=C2=A0=C2=A0 0.000000]=C2=A0=C2=A0 node=C2=A0=C2=A0 0: [mem 0x0= 000001fa4030000-0x0000001fa40effff] >>>> [=C2=A0=C2=A0=C2=A0 0.000000]=C2=A0=C2=A0 node=C2=A0=C2=A0 0: [mem 0x0= 000001fa40f0000-0x0000001fa73cffff] >>>> [=C2=A0=C2=A0=C2=A0 0.000000]=C2=A0=C2=A0 node=C2=A0=C2=A0 0: [mem 0x0= 000001fa73d0000-0x0000001fa745ffff] >>>> [=C2=A0=C2=A0=C2=A0 0.000000]=C2=A0=C2=A0 node=C2=A0=C2=A0 0: [mem 0x0= 000001fa7460000-0x0000001fa746ffff] >>>> [=C2=A0=C2=A0=C2=A0 0.000000]=C2=A0=C2=A0 node=C2=A0=C2=A0 0: [mem 0x0= 000001fa7470000-0x0000001fa758ffff] >>>> [=C2=A0=C2=A0=C2=A0 0.000000]=C2=A0=C2=A0 node=C2=A0=C2=A0 0: [mem 0x0= 000001fa7590000-0x0000001fa7ffffff] >>>> >>>> Signed-off-by: Baolin Wang >>>> --- >>>> Changes from v1: >>>> =C2=A0 - Fix building errors if CONFIG_SPARSEMEM is not selected. >>>> =C2=A0 - Use NR_MEM_SECTIONS instead of '-1' per Huang Ying. >>>> --- >>>> =C2=A0 include/linux/mmzone.h | 10 ++++++++++ >>>> =C2=A0 mm/compaction.c=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | 30= +++++++++++++++++++++++++++++- >>>> =C2=A0 2 files changed, 39 insertions(+), 1 deletion(-) >>>> >>>> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h >>>> index 5a7ada0413da..5ff1fa2efe28 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) >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return -1; >>>> =C2=A0 } >>>> +static inline unsigned long next_online_section_nr(unsigned long >>>> section_nr) >>>> +{ >>>> +=C2=A0=C2=A0=C2=A0 while (++section_nr <=3D __highest_present_section= _nr) { >>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (online_section_nr(sect= ion_nr)) >>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 re= turn section_nr; >>>> +=C2=A0=C2=A0=C2=A0 } >>>> + >>>> +=C2=A0=C2=A0=C2=A0 return NR_MEM_SECTIONS; >>>> +} >>>> + >>>> =C2=A0 /* >>>> =C2=A0=C2=A0 * These are _only_ used during initialisation, therefore= they >>>> =C2=A0=C2=A0 * can use __initdata ...=C2=A0 They could have names to = indicate >>>> diff --git a/mm/compaction.c b/mm/compaction.c >>>> index 3398ef3a55fe..c31ff6123891 100644 >>>> --- a/mm/compaction.c >>>> +++ b/mm/compaction.c >>>> @@ -229,6 +229,28 @@ static void reset_cached_positions(struct zone >>>> *zone) >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 pageblock_start_pfn(zone_end_pfn(zone) - = 1); >>>> =C2=A0 } >>>> +#ifdef CONFIG_SPARSEMEM >>>> +static unsigned long skip_hole_pageblock(unsigned long start_pfn) >>>> +{ >>>> +=C2=A0=C2=A0=C2=A0 unsigned long next_online_nr; >>>> +=C2=A0=C2=A0=C2=A0 unsigned long start_nr =3D pfn_to_section_nr(start= _pfn); >>>> + >>>> +=C2=A0=C2=A0=C2=A0 if (online_section_nr(start_nr)) >>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return 0; >>>> + >>>> +=C2=A0=C2=A0=C2=A0 next_online_nr =3D next_online_section_nr(start_nr= ); >>>> +=C2=A0=C2=A0=C2=A0 if (next_online_nr < NR_MEM_SECTIONS) >>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return section_nr_to_pfn(n= ext_online_nr); >>>> + >>> >>> I would simply inline next_online_section_nr and simplify (and add a >>> comment): >>> >>> /* >>> =C2=A0* If the PFN falls into an offline section, return the start PF= N of the >>> =C2=A0* next online section. If the PFN falls into an online section = or if >>> =C2=A0* there is no next online section, return 0. >>> =C2=A0*/ >>> static unsigned long skip_hole_pageblock(unsigned long start_pfn) >>> { >>> =C2=A0=C2=A0=C2=A0=C2=A0unsigned long nr =3D pfn_to_section_nr(start_= pfn); >>> >>> =C2=A0=C2=A0=C2=A0=C2=A0if (online_section_nr(nr)) >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return 0; >>> >>> =C2=A0=C2=A0=C2=A0=C2=A0while (++nr <=3D __highest_present_section_nr= ) { >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (online_section_nr(nr)) >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 re= turn section_nr_to_pfn(nr); >>> =C2=A0=C2=A0=C2=A0=C2=A0} >>> =C2=A0=C2=A0=C2=A0=C2=A0return 0 >>> } >>> >>> Easier, no? >> Originally I want to add a common helper like >> next_present_section_nr(), >> which can be used by other users. But yes, your suggestion is easier, >> and I am fine with that. >>=20 >>> And maybe just call that function "skip_offline_sections()" then? >>> Because we're not operating on pageblocks. >> OK. Thanks. >>=20 > > Feel free to add to the simplified version > > Acked-by: David Hildenbrand With David's above comments addressed, feel free to add Acked-by: "Huang, Ying"