Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp1870209ybb; Thu, 2 Apr 2020 08:49:17 -0700 (PDT) X-Google-Smtp-Source: APiQypIRkUjrn3kKZDvaSYl37CHvySKlj/kHm0ipU4RemmR38JAXqKVLWAwR5916Xacgmjh9nVcC X-Received: by 2002:a9d:c61:: with SMTP id 88mr3000070otr.144.1585842555550; Thu, 02 Apr 2020 08:49:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585842555; cv=none; d=google.com; s=arc-20160816; b=q82As/OLI2IQJvShrLv9mQ+PyEcW4kA37tbZAUS3Btz7h8Pu+6II9iBtVkbnMkQse5 Gr5MHYYRi0Fzco1U6xLhiTTYtrgbIvltBBXZvVW2fDrR4RI4Zf1sx4hepXjwQCig84Mi +KEZ7Y/n9xZ42yRJT31087mOg+lRmgui6MYrYiWGx9XQcJj6tVMNOdCXi5EwB2w18JUN ZenhDSie3DQHjxI8BxIXC5/LHhXdIYRuegOBAoIec7T8bgXLuGn8ywih2pNC3yH0JH34 44XQFDqp7k574Sga3gcX0TAthqbb6BRaC8V/DfnNUkfHtJF4N6YlBryVDbxtOE+jZBpg 6R8Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=hfZcbTG8tSqMJOhdU5OYV31NKlm+STRZRHqCgyABhFc=; b=CjkkKaHStPHpuuqvjMhZO4AUgoFVzffaETnA+zM0h7b8CAqudfdr+o6OP3e5gSEJAI 3sB2t55nud7vmWYv9PHro9gxOrA2QB4uYm91w3RYZj3v0J6GS84u30oUEOYt16bhxgTH 4HaKSh+T1ew7L9E7kwCh01JVX4JFW8jY3Ba0v7NCm++hfD5zsW4SsfShJ27IFgF9TMse Sh/saCKMXTMSCGI1pzxkUBS745cY/aEaRsfzjsuLfL9hYlIzDhA6PQHHpvQsmHzEZbpN FmhvR3X/a8DtV3UhRuTChzU7nLouDHcHJS7MXC5B0nZ0Txm6pZ0WZErRLCCfs4DvmMSu Fu4w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i6si2400241oor.75.2020.04.02.08.49.01; Thu, 02 Apr 2020 08:49:15 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389510AbgDBPsF (ORCPT + 99 others); Thu, 2 Apr 2020 11:48:05 -0400 Received: from mx2.suse.de ([195.135.220.15]:40392 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388677AbgDBPsF (ORCPT ); Thu, 2 Apr 2020 11:48:05 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id B3A6DAEAF; Thu, 2 Apr 2020 15:48:02 +0000 (UTC) Subject: Re: [PATCH 1/2] mm: cma: NUMA node interface To: Aslan Bakirov , akpm@linux-foundation.org Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, kernel-team@fb.com, riel@surriel.com, guro@fb.com, mhocko@kernel.org, hannes@cmpxchg.org References: <20200326212718.3798742-1-aslan@fb.com> From: Vlastimil Babka Message-ID: <65164fdb-38b0-e239-84cc-ab22b92214c5@suse.cz> Date: Thu, 2 Apr 2020 17:48:00 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <20200326212718.3798742-1-aslan@fb.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 3/26/20 10:27 PM, Aslan Bakirov wrote: > I've noticed that there is no interfaces exposed by CMA which would let me > to declare contigous memory on particular NUMA node. > > This patchset adds the ability to try to allocate contiguous memory on > specific node. I would say more explicitly that 'try' here means it will fallback to other nodes if the specific one doesn't work. At least AFAICS that's what it does by calling memblock_alloc_range_nid() with exact_nid=false. > Implement a new method for declaring contigous memory on particular node > and keep cma_declare_contiguous() as a wrapper. Should there be also support for using this node spcification in the cma=X boot param? > Signed-off-by: Aslan Bakirov ... > --- a/mm/cma.c > +++ b/mm/cma.c > @@ -220,7 +220,7 @@ int __init cma_init_reserved_mem(phys_addr_t base, phys_addr_t size, > } > > /** > - * cma_declare_contiguous() - reserve custom contiguous area > + * cma_declare_contiguous_nid() - reserve custom contiguous area > * @base: Base address of the reserved area optional, use 0 for any > * @size: Size of the reserved area (in bytes), > * @limit: End address of the reserved memory (optional, 0 for any). > @@ -229,6 +229,7 @@ int __init cma_init_reserved_mem(phys_addr_t base, phys_addr_t size, > * @fixed: hint about where to place the reserved area > * @name: The name of the area. See function cma_init_reserved_mem() > * @res_cma: Pointer to store the created cma region. > + * @nid: nid of the free area to find, %NUMA_NO_NODE for any node The bit about fallback should be also specified here. > * > * This function reserves memory from early allocator. It should be > * called by arch specific code once the early allocator (memblock or bootmem) > @@ -238,10 +239,10 @@ int __init cma_init_reserved_mem(phys_addr_t base, phys_addr_t size, > * If @fixed is true, reserve contiguous area at exactly @base. If false, > * reserve in range from @base to @limit. > */ > -int __init cma_declare_contiguous(phys_addr_t base, > +int __init cma_declare_contiguous_nid(phys_addr_t base, > phys_addr_t size, phys_addr_t limit, > phys_addr_t alignment, unsigned int order_per_bit, > - bool fixed, const char *name, struct cma **res_cma) > + bool fixed, const char *name, struct cma **res_cma, int nid) > { > phys_addr_t memblock_end = memblock_end_of_DRAM(); > phys_addr_t highmem_start;