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 F0A5BEB64D9 for ; Thu, 6 Jul 2023 09:07:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8FF668D0005; Thu, 6 Jul 2023 05:07:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8AF108D0001; Thu, 6 Jul 2023 05:07:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 776D18D0005; Thu, 6 Jul 2023 05:07:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 6767D8D0001 for ; Thu, 6 Jul 2023 05:07:12 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 2F77D1C8F5A for ; Thu, 6 Jul 2023 09:07:12 +0000 (UTC) X-FDA: 80980607904.08.A80C50B Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf08.hostedemail.com (Postfix) with ESMTP id 6375B160007 for ; Thu, 6 Jul 2023 09:07:08 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=iqDuCNjR; spf=pass (imf08.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1688634429; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=R42b/Wbgih42rOHKtCzKHwu2+V02R+fbzMrQPXy76Ow=; b=Jrj/BsZqP/wkJgZo7dlCGqEZFkuR4O+XEmp+QBCtuLpsMC6LiVSRvq65qmjhZnpSsL0YtK wcTvfHq/JElDMuQgM3aTMhQV1yWiPM6iCKFs9NbBpSZcM/+JTh9DST6UKFp94jQ3CcFoIZ kUIFnpUeqEkJaSOEG0S4MSwr1H+PBEQ= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1688634429; a=rsa-sha256; cv=none; b=44i4Hh9+urC3YoXaEAfYD2Z9gVaqsST1KeySXgAjrMzGd0Ei7TUh6yw0kGAR6Ws70LDtUj dhCh1KUc5gXjayd++E5XGXLZVkalSLscPBpoziA4GSrNFfTZ5A1KZDo1GU+2g28XJ1SuxB ynBhWEdSfY6dAJepTk+cXsZH8DWkWJo= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=iqDuCNjR; spf=pass (imf08.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1688634427; 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=R42b/Wbgih42rOHKtCzKHwu2+V02R+fbzMrQPXy76Ow=; b=iqDuCNjRQPngSNMKHsvn12WOiJm45xARQ+iaNs1+UszxfThOB85jGUHc3/2JqNd7uZxl9u xVbzYOzG1xPdoQ9vYSyGtcC+PimYwFIkmncLoB+85nOoSYh4SqpnnZHSfJeeOXmwmWCMbS tIpW+ea1EwDrGOpZVEpD8GwH5GuFqZg= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-447-Zxzq351vMymTK6DHGKH4aQ-1; Thu, 06 Jul 2023 05:07:06 -0400 X-MC-Unique: Zxzq351vMymTK6DHGKH4aQ-1 Received: by mail-wr1-f72.google.com with SMTP id ffacd0b85a97d-3143c941d0bso242064f8f.1 for ; Thu, 06 Jul 2023 02:07:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688634425; x=1691226425; h=content-transfer-encoding:in-reply-to:subject:organization:from :references:cc:to:content-language:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=R42b/Wbgih42rOHKtCzKHwu2+V02R+fbzMrQPXy76Ow=; b=chOpGngQXWmzQbR09pzKy5DV5hQq2wl80I/e4LTCWPfbXpv5q6a0JW7p81/rsEEWGq WlALF/rIUGhKKmzSh1KIWGJOFY7Jp6m+fc5hjHzCfMyH31yjZGvf3fuGDN/oV6DchQIw LVHPd0U/ctgN714vCmC/+yO6BGS7PnU1aGJ0knEyv3yxI8pdnZtQLqbrZ4bkaU42XqDi fU3zKmKNY7aaP3StUWkM+Tj7qrFpO4upLL1QW3pIYdwoBfuT4J+aFVDwS/dmTtJOKJso KeFNtvbb8kgVcLoz6Qqg4obmuhLBEq/o0D3yK8bdy4x1AXADGtLvIV2mVCZjiz64Pz1c xj1A== X-Gm-Message-State: ABy/qLaLA1R7+h2iuGK4UYhUDrvklz+a+u4vG9B1CJBawUKbL2PQNs8+ tCkjvq4GyjB7T5G5eizrG0+cp7cNf8yeol2wAKJl1cb7Ch5whTOievJPQ+nfPVd4NDFuVSmx3ap SsQH6dAmvxeoWJlQgpIk= X-Received: by 2002:a5d:6b49:0:b0:314:327:2ece with SMTP id x9-20020a5d6b49000000b0031403272ecemr949163wrw.61.1688634425368; Thu, 06 Jul 2023 02:07:05 -0700 (PDT) X-Google-Smtp-Source: APBJJlE0lxW5bimNCjuvaRNMQEhG9azRUiUxoNrsW+1xm+ZQq90JKjbkV0+LPqLy9UT6IjmiaZfQiA== X-Received: by 2002:a5d:6b49:0:b0:314:327:2ece with SMTP id x9-20020a5d6b49000000b0031403272ecemr949140wrw.61.1688634424916; Thu, 06 Jul 2023 02:07:04 -0700 (PDT) Received: from ?IPV6:2a09:80c0:192:0:5dac:bf3d:c41:c3e7? ([2a09:80c0:192:0:5dac:bf3d:c41:c3e7]) by smtp.gmail.com with ESMTPSA id j7-20020a5d6187000000b00301a351a8d6sm1280938wru.84.2023.07.06.02.07.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 06 Jul 2023 02:07:04 -0700 (PDT) Message-ID: Date: Thu, 6 Jul 2023 11:07:03 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 To: "Aneesh Kumar K.V" , linux-mm@kvack.org, akpm@linux-foundation.org, mpe@ellerman.id.au, linuxppc-dev@lists.ozlabs.org, npiggin@gmail.com, christophe.leroy@csgroup.eu Cc: Oscar Salvador , Michal Hocko , Vishal Verma References: <20230706085041.826340-1-aneesh.kumar@linux.ibm.com> <20230706085041.826340-6-aneesh.kumar@linux.ibm.com> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH v2 5/5] powerpc/book3s64/memhotplug: Enable memmap on memory for radix In-Reply-To: <20230706085041.826340-6-aneesh.kumar@linux.ibm.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 6375B160007 X-Rspam-User: X-Stat-Signature: df3c7g1nhaw9tz6twc6zhaf8dz8yy5ks X-Rspamd-Server: rspam03 X-HE-Tag: 1688634428-645612 X-HE-Meta: U2FsdGVkX18fAiqvebaHQM3AuQ4hly8HR/gRJyIzDET91I9XxJNRRWHWiVKV2MXg9koYTn5ovZR5ojT8wfqNBTo4wIST2i0I3lJSPdhByTgQYqcqCUBviNy+ncCEDU1P54yL7hMBhTHob6CA71M4RlLM2kbHz1gIEykSw80BgCnwpWlaQE4/VLAGHPbbcnHT/xr1JEQ1hlrqglw9Zb7RiS1KpFvksdeFa9XRvbz0vXIxPejtZwE3bT+Tg/QYQFvrEHvIXix3S8WWgo9yhSVzW0u0g9EG5/I3OC04xQ0WrevSFW3Bd0WEywQL808oyIQyOo5E3F82N/q7oOnWuGNX7pP0aq6mq0Z42UjvORr/S5nWczXEb/MqGcdlG5ttQu6eLg3kxQ7tVIZmAjUMC+UAd50aKhCTW2zItev8R+MXDJ+bD87MtNMxsnYgVQGDxu7Y8FdO5LKYt0Ajdts6zb9icD+4ZdCzOTS9v7CThyA29VJocAMDva+elFbSnWttbnugdlv8utk4AxCTSiC1iFW13iSzq3sH8H/RCwT4/EzYyBmUESP3t0aj54Cbs/Y6Yzbr0SlHqriTjGSrmTKPF/QIUAIhYucNU9qcEBf29lrOfzelWT6BBNTBMWGXstUUd/BWtWjSVjXN3XxtVkXJgsB4C5wSlNGhadGboIOTazU9EkFGACospplrBlcPH4hId+H4Z5BIZkjHBKbMKMZBDji1IH1v1TgGJhzPPDzx4As1OM3Cc1EcdPiKo0vkXodR7MwucOxl9mDzZBn8TvVKi6L8eodKF+F/k5jdnCxpgBHxGEOnSbxph/EMrN8ypymBQEFxS5Ba7pd44tE+5b4ie0lft7yIxz5rvXl0vwbdgA2DplXYtT7T9XgzxVP7TUgGDsPK4fPQteDwE463bMOzi1f8qiQpm7O2FH8Vm/c3WG01L61ew+k7TH35Ewsb92hk09UZflBIErE6qNoQUBkQz5S BLAx3+Go HH2/C1+VmtqUgFuHTRzTe9L9yFatkyY0rUKP5ZWWsLL0Ryr06kRFebcZOUsPCPensNiXrG7csLN9kOvfBfyHOS0bSH8iUDVdYMceMDcA9BOuMMKNNDemV7PiM18bi8CAqU18Tvb1rg8kcuoRSOj5ogz7rPwFhfbRdKBvAjvdKdl1xoAchEfx2xWF0RhAh/UA/MHaU5J8X3rHyw5pX4VbEBhavkjD8YwuXkrYauCPZv6LFiTEv7tsRjCNlat1GqNDpwf0Rdu1kse5veCM/07MGFaQeGE7EdFLs+naU5+tA6Qf6x1LYqOdzjwPxRGp8TCmRdgfwCd+DTsGYWrMlqTSYWdiille42E24BUlF9tSATKNVbZBNYTm4wYRzDGLZonK7c3qaslX1qPrT5ktaTzL6TqCh9xRQ02At/IFM/PorqFkX4fQbFhAp9a2wcw== 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 06.07.23 10:50, Aneesh Kumar K.V wrote: > Radix vmemmap mapping can map things correctly at the PMD level or PTE > level based on different device boundary checks. We also use altmap.reserve > feature to align things correctly at pageblock granularity. We can end up > loosing some pages in memory with this. For ex: with 256MB memory block > size, we require 4 pages to map vmemmap pages, In order to align things > correctly we end up adding a reserve of 28 pages. ie, for every 4096 pages > 28 pages get reserved. > > Signed-off-by: Aneesh Kumar K.V > --- > arch/powerpc/Kconfig | 1 + > arch/powerpc/mm/book3s64/radix_pgtable.c | 28 +++++++++++++++++++ > .../platforms/pseries/hotplug-memory.c | 4 ++- > 3 files changed, 32 insertions(+), 1 deletion(-) > > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig > index 116d6add0bb0..f890907e5bbf 100644 > --- a/arch/powerpc/Kconfig > +++ b/arch/powerpc/Kconfig > @@ -157,6 +157,7 @@ config PPC > select ARCH_HAS_UBSAN_SANITIZE_ALL > select ARCH_HAVE_NMI_SAFE_CMPXCHG > select ARCH_KEEP_MEMBLOCK > + select ARCH_MHP_MEMMAP_ON_MEMORY_ENABLE if PPC_RADIX_MMU > select ARCH_MIGHT_HAVE_PC_PARPORT > select ARCH_MIGHT_HAVE_PC_SERIO > select ARCH_OPTIONAL_KERNEL_RWX if ARCH_HAS_STRICT_KERNEL_RWX > diff --git a/arch/powerpc/mm/book3s64/radix_pgtable.c b/arch/powerpc/mm/book3s64/radix_pgtable.c > index a62729f70f2a..c0bd60b5fb64 100644 > --- a/arch/powerpc/mm/book3s64/radix_pgtable.c > +++ b/arch/powerpc/mm/book3s64/radix_pgtable.c > @@ -1678,3 +1678,31 @@ int pmd_free_pte_page(pmd_t *pmd, unsigned long addr) > > return 1; > } > + > +/* > + * mm/memory_hotplug.c:mhp_supports_memmap_on_memory goes into details > + * some of the restrictions. We don't check for PMD_SIZE because our > + * vmemmap allocation code can fallback correctly. The pageblock x86 also has the fallback IIRC; the concern is rather that you end up with a PTE-mapped vmemmap, which is slower at runtime than a PMD-mapped vmemmap. > + * alignment requirement is met using altmap->reserve blocks. > + */ > +bool mhp_supports_memmap_on_memory(unsigned long size) > +{ > + if (!radix_enabled()) > + return false; > + /* > + * The pageblock alignment requirement is met by using > + * reserve blocks in altmap. > + */ > + return size == memory_block_size_bytes(); > +} I really dislike such arch overrides. I think the flow should be something like that, having a generic: bool mhp_supports_memmap_on_memory(unsigned long size) { ... return arch_mhp_supports_memmap_on_memory(size)) && size == memory_block_size_bytes() && ... } where we'll also keep the pageblock check here. And a ppc specific bool arch_mhp_supports_memmap_on_memory(unsigned long size) { /* * Don't check for the vmemmap covering PMD_SIZE, we accept that * we might get a PTE-mapped vmemmap. */ return radix_enabled(); } We can then move the PMD_SIZE check into arch specific code (x86-aarch64). -- Cheers, David / dhildenb