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 X-Spam-Level: X-Spam-Status: No, score=-5.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B297CC2D0B1 for ; Thu, 6 Feb 2020 04:34:05 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 54A4520720 for ; Thu, 6 Feb 2020 04:34:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="S/K5j4bR" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 54A4520720 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id E21D96B0003; Wed, 5 Feb 2020 23:34:04 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DD3886B0006; Wed, 5 Feb 2020 23:34:04 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CC1586B0007; Wed, 5 Feb 2020 23:34:04 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0154.hostedemail.com [216.40.44.154]) by kanga.kvack.org (Postfix) with ESMTP id B4F006B0003 for ; Wed, 5 Feb 2020 23:34:04 -0500 (EST) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 5F9728248047 for ; Thu, 6 Feb 2020 04:34:04 +0000 (UTC) X-FDA: 76458434808.25.time01_5db4514aac91c X-HE-Tag: time01_5db4514aac91c X-Filterd-Recvd-Size: 6582 Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) by imf14.hostedemail.com (Postfix) with ESMTP for ; Thu, 6 Feb 2020 04:34:03 +0000 (UTC) Received: by mail-wr1-f68.google.com with SMTP id u6so5508172wrt.0 for ; Wed, 05 Feb 2020 20:34:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-disposition:in-reply-to:user-agent; bh=n249e5HNQz63XwR/f8zPGsdJTlfZY+kApZiMCpDM55E=; b=S/K5j4bRHrzkwiQ32hJBQvgOAscTM0cSw3DgQMEk6KSJQW7YU7aWyxXb+NmYXXucKB ZGSt1hOP5TNy2XH/vb+2KdOykuM8o/p9YAudV/kW3OmiAz0x7jV3g3k1QP3WuNUrRHth Kt7sDhtQ4cm6bnJICqsYpb3VkaIhRR1ymPcZWVjDMvRwQTF65sgG365abV6W82+m6JAl S1Tne6P0a6kfBSVwJH5XFJsY5aNCNtNfHZZUmgZcGTTWKBNOhgxGkR1awLmQt1w/oI5h fN+3uvwonuofoxNd9F+sq+DXtaQvzcJzZOy4Do7uwidSo2UanTIVq9OWa/nmV5/RqF+g KGPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:reply-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=n249e5HNQz63XwR/f8zPGsdJTlfZY+kApZiMCpDM55E=; b=Ho4jK08DWq20ntWC/JB63lj2kIAbvAj9Np38e1RAcfG2blVRCqoDIqC/vgOMrWobVf kJEgnzAx/cUhzbTblUbL0hj1p44y/xvcLhC+5AaVrLwczps7d1A1RvZl85tOzJ6htkkU h2OBNOHTJ22V275JBHLKkEpZRu9deFHyREOKhft5FTO9ykM2sF5xe1nPAXnRSHWmNn8S W+9isIT/eYevB4V/7WEoK6MXrVdwdFlNlXkYcb5PntVDYlKo2Z2YYRy8VWOznRfe2Umx 2EJq+7EIAxm5FY8pG0O89U8COgpHuTHCQe+MlYfw//Xx1OIqZSvQxAnx50MMeDkrAl/j QbXA== X-Gm-Message-State: APjAAAV8v5FREegj3k75PiRsmhp6819chetFhmu14XmAgcQzeRivT59a pbuhYHUDAXU7242iTG3bQFQ= X-Google-Smtp-Source: APXvYqwEzGAGucgEhWWZLDukrhQ6bAbhVdMGdJNzMuJq4Gu7wCrO0IjqhuKaoFVnPRHgAz/cZb2AiQ== X-Received: by 2002:adf:fa43:: with SMTP id y3mr1277904wrr.65.1580963642605; Wed, 05 Feb 2020 20:34:02 -0800 (PST) Received: from localhost ([185.92.221.13]) by smtp.gmail.com with ESMTPSA id d23sm2656987wra.30.2020.02.05.20.34.01 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 05 Feb 2020 20:34:02 -0800 (PST) Date: Thu, 6 Feb 2020 04:34:01 +0000 From: Wei Yang To: Baoquan He Cc: Wei Yang , Wei Yang , David Hildenbrand , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Segher Boessenkool , Andrew Morton , Michal Hocko , Oscar Salvador Subject: Re: [PATCH v1] mm/memory_hotplug: Easier calculation to get pages to next section boundary Message-ID: <20200206043401.22i2cucwqctsrtps@master> Reply-To: Wei Yang References: <20200205135251.37488-1-david@redhat.com> <20200205231945.GB28446@richard> <20200205235007.GA28870@richard> <20200206001317.GH8965@MiWiFi-R3L-srv> <20200206003736.GI8965@MiWiFi-R3L-srv> <20200206022644.6u7pxf7by2w5trmi@master> <20200206024816.GK8965@MiWiFi-R3L-srv> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200206024816.GK8965@MiWiFi-R3L-srv> User-Agent: NeoMutt/20170113 (1.7.2) 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 Thu, Feb 06, 2020 at 10:48:16AM +0800, Baoquan He wrote: >On 02/06/20 at 02:26am, Wei Yang wrote: >> On Thu, Feb 06, 2020 at 08:37:36AM +0800, Baoquan He wrote: >> >On 02/06/20 at 08:13am, Baoquan He wrote: >> >> On 02/06/20 at 07:50am, Wei Yang wrote: >> >> > On Thu, Feb 06, 2020 at 07:19:45AM +0800, Wei Yang wrote: >> >> > >On Wed, Feb 05, 2020 at 02:52:51PM +0100, David Hildenbrand wrote: >> >> > >>Let's use a calculation that's easier to understand and calculates the >> >> > >>same result. Reusing existing macros makes this look nicer. >> >> > >> >> >> > >>We always want to have the number of pages (> 0) to the next section >> >> > >>boundary, starting from the current pfn. >> >> > >> >> >> > >>Suggested-by: Segher Boessenkool >> >> > >>Cc: Andrew Morton >> >> > >>Cc: Michal Hocko >> >> > >>Cc: Oscar Salvador >> >> > >>Cc: Baoquan He >> >> > >>Cc: Wei Yang >> >> > >>Signed-off-by: David Hildenbrand >> >> > > >> >> > >Reviewed-by: Wei Yang >> >> > > >> >> > >BTW, I got one question about hotplug size requirement. >> >> > > >> >> > >I thought the hotplug range should be section size aligned, while taking a >> >> > >look into current code function check_hotplug_memory_range() guard the range. >> >> >> >> A good question. The current code should be block size aligned. I >> >> remember in some places we assume each block comprise all the sections. >> >> Can't imagine one or some of them are half section filled. >> > >> >I could be wrong, half filled block may not cause problem. >> > >> >> David must be angry about our flooding the mail list :-) > >Believe he won't, :-) If you like, we can talk off line. > >> >> Check the code again, there are two memory range check: >> >> * check_hotplug_memory_range(), block/section aligned >> * check_pfn_span(), subsection aligned >> >> The second check, check_pfn_span() in __add_pages(), enable the capability to >> add a memory range with subsection size. >> >> This means hotplug still keeps section alignment. > >memremap_pages() also call add_pages(), it doesn't have the >check_hotplug_memory_range() invocation. check_pfn_span() is made for >it specifically. > If my understanding is correct, memremap_pages() is used to add some dev memory to system. This is the use case which Dan want to enable for sub-section. Since memremap_pages() is not called in mem-hotplug path, this doesn't affect the hotplug range alignment. >> >> BTW, __add_pages() share the same logic as __remove_pages(). Why not change it >> too? Do I miss something or I don't have the latest source code? > >Good question, and I think it need. Just David is refactoring/cleaning >up the remove_pages() code path, this is found out by Segher from patch >reviewing. Ah, we may need a following cleanup :-) -- Wei Yang Help you, Help me