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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 9ED89C433DB for ; Fri, 26 Mar 2021 12:15:50 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id EC7E061A27 for ; Fri, 26 Mar 2021 12:15:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EC7E061A27 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 749856B0036; Fri, 26 Mar 2021 08:15:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 721C16B006E; Fri, 26 Mar 2021 08:15:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5C2196B0072; Fri, 26 Mar 2021 08:15:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0005.hostedemail.com [216.40.44.5]) by kanga.kvack.org (Postfix) with ESMTP id 43E0B6B0036 for ; Fri, 26 Mar 2021 08:15:49 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id EDAB018038CFA for ; Fri, 26 Mar 2021 12:15:48 +0000 (UTC) X-FDA: 77961921576.27.D2695E9 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf20.hostedemail.com (Postfix) with ESMTP id D22ACE7 for ; Fri, 26 Mar 2021 12:15:46 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 0767CAD8D; Fri, 26 Mar 2021 12:15:47 +0000 (UTC) Date: Fri, 26 Mar 2021 13:15:44 +0100 From: Oscar Salvador To: David Hildenbrand Cc: Michal Hocko , Andrew Morton , Anshuman Khandual , Vlastimil Babka , Pavel Tatashin , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v5 1/5] mm,memory_hotplug: Allocate memmap from the added memory range Message-ID: References: <40fac999-2d28-9205-23f0-516fa9342bbe@redhat.com> <92fe19d0-56ac-e929-a9c1-d6a4e0da39d1@redhat.com> <5be95091-b4ac-8e05-4694-ac5c65f790a4@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: yhd9bta5persdtuz8g6ine37jtgwdbwy X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: D22ACE7 Received-SPF: none (suse.de>: No applicable sender policy available) receiver=imf20; identity=mailfrom; envelope-from=""; helo=mx2.suse.de; client-ip=195.135.220.15 X-HE-DKIM-Result: none/none X-HE-Tag: 1616760946-644594 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 Fri, Mar 26, 2021 at 09:57:43AM +0100, Oscar Salvador wrote: > On Fri, Mar 26, 2021 at 09:52:58AM +0100, David Hildenbrand wrote: > > Might have to set fully spanned section online. (vmemmap >= SECTION_SIZE) Bleh, this morning I was in a rush and I could not think straight. I got what you mean now. Yes, if vmemmap pages fully span a section, we need to online that section before calling online_pages(), otherwise we would left that section offline. > > We'll not call the memory notifier (e.g., MEM_ONLINE) for the vmemmap. The Well, since it is not actual memory we might do not need to, but > > 1. We won't allocate extended struct pages for the range. Don't think this > > is really problematic (pages are never allocated/freed, so I guess we don't > > care - like ZONE_DEVICE code). Probably not worth for vmemmap > > > > 2. We won't allocate kasan shadow memory. We most probably have to do it > > explicitly via kasan_add_zero_shadow()/kasan_remove_zero_shadow(), see > > mm/memremap.c:pagemap_range() we should be calling those kasan_{add,remove}. We can stuff that into the vmemmap helpers, so everything remains contained. > > > > > > Further a locking rework might be necessary. We hold the device hotplug > > lock, but not the memory hotplug lock. E.g., for get_online_mems(). Might > > have to move that out online_pages. That is a good point. I yet have to think about it further, but what about moving those mem_hotplug_{begin,done} to memory_block_{offline,online}. Something like: static int memory_block_online(...) { int ret; mem_hotplug_begin(); if (nr_vmemmap_pages) vmemmap_hotplug_init(); ret = online_pages(...); if (ret) /* * Cleanup stuff */ mem_hotplug_done(); } As you said, you finished cleaning up those users who were calling {online,offline}_pages() directly, but is this something that we will forbidden in the future too? My question falls within "Are we sure we will not need that locking back in those functions because that is something we will not allow to happen?" -- Oscar Salvador SUSE L3