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 87AC1C7EE43 for ; Tue, 13 Jun 2023 01:09:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1EAF68E0005; Mon, 12 Jun 2023 21:09:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 19B668E0003; Mon, 12 Jun 2023 21:09:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 063238E0005; Mon, 12 Jun 2023 21:09:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id EACEB8E0003 for ; Mon, 12 Jun 2023 21:09:20 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id B4D46AF7EE for ; Tue, 13 Jun 2023 01:09:20 +0000 (UTC) X-FDA: 80895941280.12.271C72C Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by imf18.hostedemail.com (Postfix) with ESMTP id B763F1C000C for ; Tue, 13 Jun 2023 01:09:17 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=fbUK3Gnp; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf18.hostedemail.com: domain of ying.huang@intel.com designates 192.55.52.88 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=1686618558; 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=k4Vxi1J0614Nh7slahQ4CrRvk/D/oyxhlAl5Hmaj5IE=; b=jYUMWICYJ6ny3q3rDhRb+wvcECmnmxEGUXlIaASMbOBw9XOTId6zGmOy3yaXo2yvjaOQxd m+QwEyboKgsrFiNxOSCsFfG7EFMUAI5HAXAERHXUfG1wZysuJeFRXo8UxC84qO+KnQzF09 21lynjRHd1h0kb8XrROcS19Azdkr3LA= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=fbUK3Gnp; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf18.hostedemail.com: domain of ying.huang@intel.com designates 192.55.52.88 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1686618558; a=rsa-sha256; cv=none; b=uPR5bL1t1FSsTJvyaUzVRljXhHLTqahHOKRIDmxkuNoGng7307ltpz1Cx13OnQf/TRwCG/ N0axBvkyjCNCbVakl0CWyXHb8AGP8UJQ+QHwrVZgsSWJ7Ju+OUFw8B0hOXEJCtMrM0XqSk gpUWryS+LaYAJ+XL37VO3ZMfxPrlzbg= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1686618557; x=1718154557; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version; bh=yYYeR72UE/HCu+Yb/b6ve+hZAEqD/EERuOmUYcR8bXs=; b=fbUK3Gnp+zurfw5Nrv7FVidnPlcgnx0iymdEA655ovEhH19A6uwamuii XW6cD4G7XTmTTgMAYZ/1NmkJw8ApCfAv05JyVIU1WrKp/NFX7ifVt+54s HzDT8aqwkepRzmWGOuTPaxH6GIm6G8YYU+r9ygi3okjTUy0Gguj6WGGvJ WXf8QULfIcBXagtBTOJC0yGoFDlk2ZM0m4yzd/6ul35Xc+47p0atiJW8w HkMJtNtla0Fe6nSy99soiFjgUIIbtFBJLnOxsQ4wOo9fT1cQB9Ax26VMJ NmeMdLriFhASyXcFg6jNXihsgX864EWCcarfVy21b0qiNZOY7OnmpdV+4 w==; X-IronPort-AV: E=McAfee;i="6600,9927,10739"; a="386590094" X-IronPort-AV: E=Sophos;i="6.00,238,1681196400"; d="scan'208";a="386590094" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Jun 2023 18:09:16 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10739"; a="958221558" X-IronPort-AV: E=Sophos;i="6.00,238,1681196400"; d="scan'208";a="958221558" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by fmsmga006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Jun 2023 18:09:14 -0700 From: "Huang, Ying" To: Baolin Wang Cc: , , , , , Subject: Re: [PATCH] mm: compaction: skip memory hole rapidly when isolating migratable pages References: <8cc668b77c8eb2fa78058b3d81386ebed9c5a9cd.1686294549.git.baolin.wang@linux.alibaba.com> <87sfax6v7c.fsf@yhuang6-desk2.ccr.corp.intel.com> Date: Tue, 13 Jun 2023 09:08:01 +0800 In-Reply-To: (Baolin Wang's message of "Mon, 12 Jun 2023 17:36:43 +0800") Message-ID: <87h6rc6ufi.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: B763F1C000C X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: khk6md6naftxhsahhtjay591u5x1j84t X-HE-Tag: 1686618557-918488 X-HE-Meta: U2FsdGVkX1/rH1Bo7oLn39LoW1KDj/eOZA0MfDdiafMpaYA0VtM1bbfepQpuOYd+0IEP6ZkPVsa9xY3ENuJz2zN+yMQhyJF4nZ2SK3Gww9CypQyXZ0X1WT69vkB0LY8ntPsbbIlXaaN48P7Nlm5bYw/mLjowyuBWQHDYxFMHpyMl0q42YvP9h+ccNYSc6Fq30SaWRq95V+W1p5C1nNHT9iILwF8HkUVm736qmlQkM3m+lcC69LU0N6V6I+RqlgDALuqWUkvBn1yXtKZhMEP1577J6MutFLvSn1/dK9qLregGn+6amDSfI8p/LUibDMVtxXgBO63GLYN4CPmWqHEOjCtNQ0WyKWDOEUKDBQv1l/erZU25pcJCJAVnhZQkhviDt5vxligkAKukG1CJFIL+KrJidiCAjkmIV9xjE3REFSCkgz7VQL/i+ltyfcIZg+dl3WskOMOndmi78miPtWRDpxyGStDZOSPFd9oiN7MmSe7HktoILYo6Sq7OfY9YrIfL1BQ6rSsnYlQQMN3JKrWmKw6yiB9bfZNSZFkRzXa+HGmDAO11TuM+cXEBSk0P4YOylABSiXnSuiGr20/lB1pFOd+2THTMmY8XIh7gvE/jB15dWVg7IxsPhCExO42ED2tdgFOUGPYPBUw1H8rXVtO3r1grbWOR5ac46a2rvqe+PbtwMQo1dmRvZqWx8m24Et1dsmtSfwmAgltTf/s8IcVQbCn+ALZw6lIuPnCUNBdNCfSuVJFcAyYrsTL+rZr6CLzHvo7CDFGdIIwK/IMFrl+xx4x+qWs89dXMfQUuduxjTfMcDU74Bvg7e5mb34NzdFOn1i/0Bagujkg/MC9TbdN10sfCbQuYZ4pdvbrFm4Qdz3J7LSHqF62vgYtiojHFAdFuuevg+bd1Os4Ga/9NxqlkWVvn5ssSpVEbLYigJwoRaVjPyFIz5Hq1vwvPwy0C7Uqf8XOoaITrtTOlzN81bw3 8WlJ4tHP BawMBqefc+OJf7LrLuYbPqY+2kWGKrB67LHhvl5mJ2xFMQJRH8AYKW/yM3y0clZeJ3ZIvMGNcIu63Sbs0xxGlcG7MsLXl1Y+ufrmBd7Rz0X7v4d9+6KanMVRB5TIhUgooQTf+o399KEBupQDf2B66qE0FnDsekQ1Mp07W58RHhws9fuTUYaTIXoUJeJcZC6q+LjnW6R7HcQLalVU= 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 6/12/2023 2:39 PM, Huang, Ying wrote: >> 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. > > I am struggling to find a readable macro for these '-1UL', since the > '-1UL' in next_online_section_nr() indicates that it can not find an > online section. However the '-1' in skip_hole_pageblock() indicates > that it can not find an online pfn. > > So after more thinking, I will change to return 'NR_MEM_SECTIONS' if > can not find next online section in next_online_section_nr(). And in > skip_hole_pageblock(), I will change to return 0 if can not find next > online pfn. What do you think? > > 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 0; > > next_online_nr = next_online_section_nr(start_nr); > if (next_online_nr < NR_MEM_SECTIONS) > return section_nr_to_pfn(next_online_nr); > > return 0; > } Sounds good to me. Best Regards, Huang, Ying >>> + >>> + 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()? > > Yes, it's in my todo list with some measurement data. > > Thanks for your comments.