Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp3714534pxu; Sun, 11 Oct 2020 21:40:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyUf7R41N7mUiwUPLycl/cIrsD0X7gmRosycg+NuJs/fGgURdVV+zDxoVzYAf2m2gTZs+Uv X-Received: by 2002:a05:6402:1c1b:: with SMTP id ck27mr12346942edb.218.1602477640438; Sun, 11 Oct 2020 21:40:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1602477640; cv=none; d=google.com; s=arc-20160816; b=YLkzYmx11weVVrtGpSvQuIInAVERNfO7E9JqaOxcUOMmmmAeJtsW+x73bY/Rn+I5t8 zyvhgmZQf5q/bAh0tnim6d4b1UPFJAXNtFszBLJD05mxwT7pFLfFnPIKpt7SfY0gTt2u dZXBv8lqnRadzg4d1zVegzkE6EesWZMq1cVCQfm1U/HuwRqNpvNGq4ZgApUWDaMRd/L9 vXK6tRoH4RRQsI+0B0Nsk9TiMB/EUm34QPsmFPw7ISytS1QDmlmoKkro2E2Wg+q8fo04 ZuhFWKum4MNXJyEXtgMa57s8+2ASymGkYZo9iog99si2Tu+vNdDSPIBSGnIbeoD/DxP9 X9kA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:reply-to:dkim-signature; bh=CyBvKJlwEt88IRf9EfgPjGolLJMwPUsWY1lJjJpIoqg=; b=s+RLqvxdHk1D3tnmoC841ZGFoq9YFJRf/QHOnyA3g+T+WccSO0CN40RNa5MfzFw3i5 jzAmzg9xi9WB3Eb0StYGNjoF6CC4wc2cWQlYnWgTRXbAK+6JPmMT3LynD28JZcFSKlGg TdxhxKkoDMd0n9G3SzQEC8P3bC0gdwo0gMClMlD2mxg4OFzifhOKbFDBrA9hPKa4MnZA 5mQVEIVTmr7DnUv2H1x3gzHQsa0wMKIvgnSQ6azJfaksMMId6SJS77CfN1/zbj6xS0dA 05z6tohRIyZhKHTs6w0JaRE1alwWYu0nOivQnPjAdASKkhezsslYXM98k86w+O1Vttc0 PAhA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="h/5YTOeb"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k18si8930422edq.480.2020.10.11.21.40.17; Sun, 11 Oct 2020 21:40:40 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="h/5YTOeb"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726486AbgJLCy5 (ORCPT + 99 others); Sun, 11 Oct 2020 22:54:57 -0400 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:27024 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725917AbgJLCy4 (ORCPT ); Sun, 11 Oct 2020 22:54:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1602471295; h=from:from:reply-to: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=CyBvKJlwEt88IRf9EfgPjGolLJMwPUsWY1lJjJpIoqg=; b=h/5YTOebSmv3JAugn9+5jTpB8ParvWPqJGMuIahepfFatyBFP07yQ5uH41eiOYkr5fHWsb RnLo2Q5wC1nUZzJNO5JXEK+jRAJ4QT1wZ2eMbzruhajJPtPPFnBD77Un2KYzxZJTWMkZ48 dyyAj7Jz8I2ODX2c96s9rXWVTciyJaw= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-424-IsD0W383MImwHkY_DoC6cA-1; Sun, 11 Oct 2020 22:54:51 -0400 X-MC-Unique: IsD0W383MImwHkY_DoC6cA-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id C6612185A0C0; Mon, 12 Oct 2020 02:54:48 +0000 (UTC) Received: from [10.64.54.32] (vpn2-54-32.bne.redhat.com [10.64.54.32]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C50345C225; Mon, 12 Oct 2020 02:54:42 +0000 (UTC) Reply-To: Gavin Shan Subject: Re: [PATCH v3] arm64/mm: add fallback option to allocate virtually contiguous memory To: Anshuman Khandual , Sudarshan Rajagopalan , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Cc: Mark Rutland , Will Deacon , David Hildenbrand , Catalin Marinas , Steven Price , Andrew Morton , Logan Gunthorpe References: <9e6178d2828e9c36275487263c5842c688e5b731.1601582954.git.sudaraja@codeaurora.org> <49dd60a7-25f4-8dc1-b905-088dff2a84fb@arm.com> From: Gavin Shan Message-ID: Date: Mon, 12 Oct 2020 13:54:40 +1100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.0 MIME-Version: 1.0 In-Reply-To: <49dd60a7-25f4-8dc1-b905-088dff2a84fb@arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/6/20 2:36 PM, Anshuman Khandual wrote: > On 10/02/2020 01:46 AM, Sudarshan Rajagopalan wrote: >> When section mappings are enabled, we allocate vmemmap pages from physically >> continuous memory of size PMD_SIZE using vmemmap_alloc_block_buf(). Section >> mappings are good to reduce TLB pressure. But when system is highly fragmented >> and memory blocks are being hot-added at runtime, its possible that such >> physically continuous memory allocations can fail. Rather than failing the >> memory hot-add procedure, add a fallback option to allocate vmemmap pages from >> discontinuous pages using vmemmap_populate_basepages(). >> >> Signed-off-by: Sudarshan Rajagopalan >> Cc: Catalin Marinas >> Cc: Will Deacon >> Cc: Anshuman Khandual >> Cc: Mark Rutland >> Cc: Logan Gunthorpe >> Cc: David Hildenbrand >> Cc: Andrew Morton >> Cc: Steven Price >> --- >> arch/arm64/mm/mmu.c | 11 +++++++++-- >> 1 file changed, 9 insertions(+), 2 deletions(-) >> It looks good to me with Anshuman's comments fixed: Reviewed-by: Gavin Shan >> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c >> index 75df62f..11f8639 100644 >> --- a/arch/arm64/mm/mmu.c >> +++ b/arch/arm64/mm/mmu.c >> @@ -1121,8 +1121,15 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node, >> void *p = NULL; >> >> p = vmemmap_alloc_block_buf(PMD_SIZE, node, altmap); >> - if (!p) >> - return -ENOMEM; >> + if (!p) { >> + /* >> + * fallback allocating with virtually >> + * contiguous memory for this section >> + */ > > Mapping is always virtually contiguous with or without huge pages. > Please drop this comment here, as it's obvious. > >> + if (vmemmap_populate_basepages(addr, next, node, NULL)) >> + return -ENOMEM; > > Please send in the 'altmap' instead of NULL for allocation from > device memory if and when requested. > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >