Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp932790imu; Wed, 9 Jan 2019 08:43:42 -0800 (PST) X-Google-Smtp-Source: ALg8bN40wG7iokz+cP8oF5qcgpM1fC2DVpZkgNHJE8NeR+pDiDlBCDUT9+5DTZhd2Iscwfy65gl5 X-Received: by 2002:a17:902:1101:: with SMTP id d1mr6652247pla.136.1547052222144; Wed, 09 Jan 2019 08:43:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547052222; cv=none; d=google.com; s=arc-20160816; b=UKmDhqN/5U7JaZTW2J9uS98IPObmt7MmMXiaeHxfT1nZVXfMDSvIPvSoVX0LDfSwWl pEvYrsagf11qt5FWGlN/yKeAxr9Rjg4//1SIpZFd02mn1FzNZb7KsGpRb/3QrU6Ru7l7 fJifxPdbHNNpCkWZbbHOOl6dYcOATdJvJm8LFEYz8CBOLkRpd/E5wiHqmEprl6WNkbCh pzuPevhHc2I1CgyfJjlh+H4jkEX4ZwjDeC6N35n1hQ12DHcI044NeLSNZ/tDxmNYkHYm Tig0/92kKzCY46W6kkJAJmLdYXlY6gVuXE0+CthFXG4S0Z1mg7QkGQL90758Dt1IJ+A0 yzrA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:date:cc:to:from:subject:message-id; bh=H3eJDd1yJeVfDVTg6pjbdfuW01Mh++zUqKlTTppHX0g=; b=LRVZWKHQl0xZ0VeYQI2yEAh5eWGwIa5fRa75HlhfSJob6x+noqOtNCA/LNNofTnwdZ heqhcjR1vhct7Z98f5G8+RQOGJjooP488GeiBIY5ueQR9Ex4XC/NdTSjpChGzxE+iBxj mpCpro2gTR78NhkD+1FyP8EZCtzkAZAlGQ3e8TgCuTx31gNVXdU8gfA2Q0wnInrOL1xa +yYtD4WYItn03Brw+5P1YaDJ/wGo2BHj7U0LissybySNLxABukpj4FJKOXSIUa1PTLg2 UDbCm6V7pLhp3fGq9MvFYzhlbbKD5xQggNEGN++qTwhrmjgAeb00NLqLxH98/MuGXapd pMTQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q26si5153177pgk.162.2019.01.09.08.43.26; Wed, 09 Jan 2019 08:43:42 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732649AbfAIQRM (ORCPT + 99 others); Wed, 9 Jan 2019 11:17:12 -0500 Received: from mga01.intel.com ([192.55.52.88]:65156 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731219AbfAIQRM (ORCPT ); Wed, 9 Jan 2019 11:17:12 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Jan 2019 08:17:11 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,458,1539673200"; d="scan'208";a="105258001" Received: from ahduyck-desk1.jf.intel.com ([10.7.198.76]) by orsmga007.jf.intel.com with ESMTP; 09 Jan 2019 08:17:11 -0800 Message-ID: <54c280dbd0ff8e17a6c465778c98e2dbbbde7918.camel@linux.intel.com> Subject: Re: [PATCH v8] mm/page_alloc.c: memory_hotplug: free pages as higher order From: Alexander Duyck To: Arun KS , arunks.linux@gmail.com, akpm@linux-foundation.org, mhocko@kernel.org, vbabka@suse.cz, osalvador@suse.de, linux-kernel@vger.kernel.org, linux-mm@kvack.org Cc: getarunks@gmail.com Date: Wed, 09 Jan 2019 08:17:11 -0800 In-Reply-To: <1547032395-24582-1-git-send-email-arunks@codeaurora.org> References: <1547032395-24582-1-git-send-email-arunks@codeaurora.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 (3.28.5-2.fc28) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2019-01-09 at 16:43 +0530, Arun KS wrote: > When freeing pages are done with higher order, time spent on coalescing > pages by buddy allocator can be reduced. With section size of 256MB, hot > add latency of a single section shows improvement from 50-60 ms to less > than 1 ms, hence improving the hot add latency by 60 times. Modify > external providers of online callback to align with the change. > > Signed-off-by: Arun KS > Acked-by: Michal Hocko > Reviewed-by: Oscar Salvador > --- > Changes since v7: > - Rebased to 5.0-rc1. > - Fixed onlined_pages accounting. > - Added comment for return value of online_page_callback. > - Renamed xen_bring_pgs_online to xen_online_pages. As far as the renaming you should try to be consistent. If you aren't going to rename generic_online_page or hv_online_page I wouldn't bother with renaming xen_online_page. I would stick with the name xen_online_page since it is a single high order page that you are freeing. > > Changes since v6: > - Rebased to 4.20 > - Changelog updated. > - No improvement seen on arm64, hence removed removal of prefetch. > > Changes since v5: > - Rebased to 4.20-rc1. > - Changelog updated. > > Changes since v4: > - As suggested by Michal Hocko, > - Simplify logic in online_pages_block() by using get_order(). > - Seperate out removal of prefetch from __free_pages_core(). > > Changes since v3: > - Renamed _free_pages_boot_core -> __free_pages_core. > - Removed prefetch from __free_pages_core. > - Removed xen_online_page(). > > Changes since v2: > - Reuse code from __free_pages_boot_core(). > > Changes since v1: > - Removed prefetch(). > > Changes since RFC: > - Rebase. > - As suggested by Michal Hocko remove pages_per_block. > - Modifed external providers of online_page_callback. > > v7: https://lore.kernel.org/patchwork/patch/1028908/ > v6: https://lore.kernel.org/patchwork/patch/1007253/ > v5: https://lore.kernel.org/patchwork/patch/995739/ > v4: https://lore.kernel.org/patchwork/patch/995111/ > v3: https://lore.kernel.org/patchwork/patch/992348/ > v2: https://lore.kernel.org/patchwork/patch/991363/ > v1: https://lore.kernel.org/patchwork/patch/989445/ > RFC: https://lore.kernel.org/patchwork/patch/984754/ > --- > drivers/hv/hv_balloon.c | 6 +++-- > drivers/xen/balloon.c | 21 +++++++++++------ > include/linux/memory_hotplug.h | 2 +- > mm/internal.h | 1 + > mm/memory_hotplug.c | 51 +++++++++++++++++++++++++++++++----------- > mm/page_alloc.c | 8 +++---- > 6 files changed, 62 insertions(+), 27 deletions(-) > > diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c > index 5301fef..211f3fe 100644 > --- a/drivers/hv/hv_balloon.c > +++ b/drivers/hv/hv_balloon.c > @@ -771,7 +771,7 @@ static void hv_mem_hot_add(unsigned long start, unsigned long size, > } > } > > -static void hv_online_page(struct page *pg) > +static int hv_online_page(struct page *pg, unsigned int order) > { > struct hv_hotadd_state *has; > unsigned long flags; > @@ -783,10 +783,12 @@ static void hv_online_page(struct page *pg) > if ((pfn < has->start_pfn) || (pfn >= has->end_pfn)) > continue; > > - hv_page_online_one(has, pg); > + hv_bring_pgs_online(has, pfn, (1UL << order)); > break; > } > spin_unlock_irqrestore(&dm_device.ha_lock, flags); > + > + return 0; > } > I would hold off on adding return values until you actually have code that uses them. It will make things easier if somebody has to backport this to a stable branch and avoid adding complexity until it is needed. Also the patch description doesn't really explain that it is doing this so it might be better to break it off into a separate patch so you can call out exactly why you are adding a return value in the patch description. - Alex