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=-15.7 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,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 4740EC4708F for ; Wed, 2 Jun 2021 12:14:57 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C0772613B1 for ; Wed, 2 Jun 2021 12:14:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C0772613B1 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 535C26B006C; Wed, 2 Jun 2021 08:14:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4BEDC6B006E; Wed, 2 Jun 2021 08:14:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2EACC6B0070; Wed, 2 Jun 2021 08:14:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0002.hostedemail.com [216.40.44.2]) by kanga.kvack.org (Postfix) with ESMTP id ED9D36B006C for ; Wed, 2 Jun 2021 08:14:55 -0400 (EDT) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 88CBDDB39 for ; Wed, 2 Jun 2021 12:14:55 +0000 (UTC) X-FDA: 78208677750.15.5F958A6 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf12.hostedemail.com (Postfix) with ESMTP id 5C1D242D for ; Wed, 2 Jun 2021 12:14:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1622636094; h=from:from: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; bh=+WZvzkWyoU33l+EoH2um7bddlB7uqhofjcxdl6V4QOM=; b=T7jvgd/JRD6/014SCN3fTysX9emAA6/ev8Wj5oSlSXYz1PUdGWxVmvb+lD32MwvhJzNAEI Ek4D1dI9/hN081vKlQhoH5CRuhZy9Ru0yElEynA70lO20DHIdiijrHbcnljtLPNSzAW7B8 dyQV5MbqwTPQm1iigPyPuob/gHXPZag= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-187-eYq4b-NYMomLxU3Qo-DKwg-1; Wed, 02 Jun 2021 08:14:51 -0400 X-MC-Unique: eYq4b-NYMomLxU3Qo-DKwg-1 Received: by mail-wm1-f72.google.com with SMTP id x20-20020a1c7c140000b029018f49a7efb7so2115624wmc.1 for ; Wed, 02 Jun 2021 05:14:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:references:from:organization:subject :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=+WZvzkWyoU33l+EoH2um7bddlB7uqhofjcxdl6V4QOM=; b=NbwCpFiwRP7tumElrDriiptVseLF30SfxKTsfcJUexVzE+XWw6jzDjDp/ehUHLrQ/F M80o2ex4vlp7sYXWlTKfJa0ptFt7U7DgN43deILRdl9Q9yJmxTefSHPv4YBiIkyxvn0Q SoeT59rrT64xIHoWXe7l6M9fwUft9KpTr+FvI8DsdZI6bdTg/7PwTA4raslL8g8j88q4 KUZ1ijBZY7LPJDHkrH7uO1WAhHlrqJXKVPveP6Ac5g7AHKssLHpNVXAV1v0i31GKhoyA XjV9bE3Pw7OdbqYmKM5xchDCd3wVakQlLsDCFAXOMDCwynlTPewjfa/YeaUK/t+9KIlI JjbQ== X-Gm-Message-State: AOAM531H5TdveoRJ6BfbSvA164QoU6mSZNKjy+VOfGjHH1UqJfXw/DHB IE5CfwuLwlFNLLYiSAvbTSCfadKILROI0kfAt0gMGIAulKx2DYVjrSgZkuNLWQKv5Bb2UsLAX+s nTYG0kyPV9aA= X-Received: by 2002:a7b:c396:: with SMTP id s22mr10160295wmj.131.1622636090058; Wed, 02 Jun 2021 05:14:50 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwGpbVgDrSlfIRKic51uMtC0PdZNIeN370u1E5fK+jYKeWSaQQbVkV3u6Hl/kPrdrf6iUsjYQ== X-Received: by 2002:a7b:c396:: with SMTP id s22mr10160274wmj.131.1622636089857; Wed, 02 Jun 2021 05:14:49 -0700 (PDT) Received: from [192.168.3.132] (p5b0c6b6d.dip0.t-ipconnect.de. [91.12.107.109]) by smtp.gmail.com with ESMTPSA id r7sm2581509wmq.3.2021.06.02.05.14.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Jun 2021 05:14:49 -0700 (PDT) To: Max Gurtovoy , linux-nvme@lists.infradead.org, dan.j.williams@intel.com, logang@deltatee.com, linux-mm@kvack.org, hch@lst.de Cc: sagi@grimberg.me, oren@nvidia.com, linux-kernel@vger.kernel.org, akpm@linux-foundation.org References: <20210602111055.10480-1-mgurtovoy@nvidia.com> <20210602111055.10480-2-mgurtovoy@nvidia.com> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH 1/3] mm,memory_hotplug: export mhp min alignment Message-ID: <283740c3-db3f-3c9a-2954-f1c037a13e86@redhat.com> Date: Wed, 2 Jun 2021 14:14:48 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <20210602111055.10480-2-mgurtovoy@nvidia.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="T7jvgd/J"; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf12.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 216.205.24.124) smtp.mailfrom=david@redhat.com X-Stat-Signature: gd3ktim78qit8h186ohrrgo86th6fgoh X-Rspamd-Queue-Id: 5C1D242D X-Rspamd-Server: rspam02 X-HE-Tag: 1622636077-489673 Content-Transfer-Encoding: quoted-printable 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 02.06.21 13:10, Max Gurtovoy wrote: > Hotplugged memory has alignmet restrictions. E.g, it disallows all > operations smaller than a sub-section and only allow operations smaller > than a section for SPARSEMEM_VMEMMAP. Export the alignment restrictions > for mhp users. >=20 > Signed-off-by: Max Gurtovoy > --- > include/linux/memory_hotplug.h | 5 +++++ > mm/memory_hotplug.c | 33 +++++++++++++++++++-------------- > 2 files changed, 24 insertions(+), 14 deletions(-) >=20 > diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotp= lug.h > index 28f32fd00fe9..c55a9049b11e 100644 > --- a/include/linux/memory_hotplug.h > +++ b/include/linux/memory_hotplug.h > @@ -76,6 +76,7 @@ struct mhp_params { > =20 > bool mhp_range_allowed(u64 start, u64 size, bool need_mapping); > struct range mhp_get_pluggable_range(bool need_mapping); > +unsigned long mhp_get_min_align(void); > =20 > /* > * Zone resizing functions > @@ -248,6 +249,10 @@ void mem_hotplug_done(void); > ___page; \ > }) > =20 > +static inline unsigned long mhp_get_min_align(void) > +{ > + return 0; > +} > static inline unsigned zone_span_seqbegin(struct zone *zone) > { > return 0; > diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c > index 9e86e9ee0a10..161bb6704a9b 100644 > --- a/mm/memory_hotplug.c > +++ b/mm/memory_hotplug.c > @@ -270,24 +270,29 @@ void __init register_page_bootmem_info_node(struc= t pglist_data *pgdat) > } > #endif /* CONFIG_HAVE_BOOTMEM_INFO_NODE */ > =20 > +/* > + * Disallow all operations smaller than a sub-section and only > + * allow operations smaller than a section for > + * SPARSEMEM_VMEMMAP. Note that check_hotplug_memory_range() > + * enforces a larger memory_block_size_bytes() granularity for > + * memory that will be marked online, so this check should only > + * fire for direct arch_{add,remove}_memory() users outside of > + * add_memory_resource(). > + */ > +unsigned long mhp_get_min_align(void) > +{ > + if (IS_ENABLED(CONFIG_SPARSEMEM_VMEMMAP)) > + return PAGES_PER_SUBSECTION; > + return PAGES_PER_SECTION; > +} > +EXPORT_SYMBOL_GPL(mhp_get_min_align); We have to main interfaces to "hotplug" memory: a) add_memory() and friends for System RAM, which have memory block=20 alignment requirements. b) memremap_pages(), which has the alignemnt requirements you mention her= e. I feel like what you need would better be exposed in mm/memremap.c, for=20 example, via "memremap_min_alignment" so it matches the "memremap_pages"=20 semantics. And then, memremap_pages() is only available with CONFIG_ZONE_DEVICE,=20 which depends on SPARSEMEM_VMEMMAP. So you'll always have=20 PAGES_PER_SUBSECTION. I can already spot "memremap_compat_align", maybe you can reuse that or=20 handle it accordingly in there? --=20 Thanks, David / dhildenb