From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 9BFC9A04B7 for ; Thu, 17 Sep 2020 15:05:49 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 43C501D619; Thu, 17 Sep 2020 15:05:49 +0200 (CEST) Received: from mail-wm1-f66.google.com (mail-wm1-f66.google.com [209.85.128.66]) by dpdk.org (Postfix) with ESMTP id 0BC341C10F for ; Thu, 17 Sep 2020 15:05:47 +0200 (CEST) Received: by mail-wm1-f66.google.com with SMTP id l15so4415684wmh.1 for ; Thu, 17 Sep 2020 06:05:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mayadata-io.20150623.gappssmtp.com; s=20150623; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=gpqf2WAm/E0/VXwPNPLB+uBN+MZucmE8Im/mZVBvvwQ=; b=vS3nXGeAqcdzXzgqWNbBXeSq6qu1gq5rRfZ+kuzFBtFYh0MR6pwEtNBA0nttkQ2f2r A1rlgE7lVymjqeyWkeWklxqhNTPZ/ujOy12FmVqwMhq1b/OMc8P75HPk26FRx9OWUxt2 k47L5LSARL64zIrOnKk1BqLgZC02FdpoDD2hJCnSvUWp8USWyGdhazzjTLY1uQ0thhcq BEK7C5VnzTY4ziTpvNCSiuRJt9rjNOmpeqeyaihBPq25lXnXOVQyzEhCHxzrb2nc7FBd T7dB9SQr4iZpyxYpox8jhc92aScSWDwf3biM3+ywp8s8t6D8k0VxCGwl67LPRVzh/YTT k/1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=gpqf2WAm/E0/VXwPNPLB+uBN+MZucmE8Im/mZVBvvwQ=; b=POBUSbjKNT7qK7LuyKn6bzxGJYjuwaUWwE8hLZq0kh1Mfq93M12vGmWIQilpJ87qTV 7JqNrwVhlJcQNwbd1h5yT+6AkZDqokOcSWEQpwxPti/IeMeRvv3OGA1+r4jIbuf65Eye zvBbNzHakC1gRF4Ldhc6yUxxSlJQ3EE7no8d1Jy30axh75PSKauWDpHDwgbtOtsU1/kC sNo1u1Vq2gWHjfv6+N+Bdg7JhMpJDvuiktjGJ1Mp0xcbxhMdCmaKD97EvjMIMxol7bp0 yw0cqD9R5JVh+uEh4rGEvuwpSEqXifMPEW49aPhTYAjRfSIjbjJAKLrUKwQSvmW8txT4 igDQ== X-Gm-Message-State: AOAM531KcIgrtchkSQu3y5frOBWZCpsnC94lN9585Hp7d+euVt62rzYa nlE/7cHz/qrPLYe9l/kqHIKVNNmSYOskK0kk X-Google-Smtp-Source: ABdhPJxxuWjuLRxORCyrp4NDJSHP1awKDPS4axEWUgmqacrIrWd57hWOUNKgrGK7dfYpkZIun4ZdcA== X-Received: by 2002:a1c:6607:: with SMTP id a7mr9815715wmc.142.1600347946472; Thu, 17 Sep 2020 06:05:46 -0700 (PDT) Received: from [192.168.0.33] (cpc98320-croy25-2-0-cust77.19-2.cable.virginm.net. [80.235.134.78]) by smtp.gmail.com with ESMTPSA id d2sm39597451wro.34.2020.09.17.06.05.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 17 Sep 2020 06:05:45 -0700 (PDT) From: Nick Connolly X-Google-Original-From: Nick Connolly To: "Burakov, Anatoly" Cc: dev@dpdk.org, nicolas.dichtel@6wind.com, stable@dpdk.org References: <20200805122640.13884-1-nick.connolly@mayadata.io> <8ebfbd1f-9a2b-3421-1d35-a3cf070ce8df@mayadata.io> Message-ID: Date: Thu, 17 Sep 2020 14:05:44 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Subject: Re: [dpdk-stable] [PATCH] mem: fix allocation failure on non-NUMA kernel X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" Hi Anatoly, Thanks.  My recollection is that all of the NUMA configuration flags were set to 'n'. Regards, Nick On 17/09/2020 13:57, Burakov, Anatoly wrote: > On 17-Sep-20 1:29 PM, Nick Connolly wrote: >> Hi Anatoly, >> >> Thanks for the response.  You are asking a good question - here's >> what I know: >> >> The issue arose on a single socket system, running WSL2 (full Linux >> kernel running as a lightweight VM under Windows). >> The default kernel in this environment is built with CONFIG_NUMA=n >> which means get_mempolicy() returns an error. >> This causes the check to ensure that the allocated memory is >> associated with the correct socket to fail. >> >> The change is to skip the allocation check if check_numa() indicates >> that NUMA-aware memory is not supported. >> >> Researching the meaning of CONFIG_NUMA, I found >> https://cateee.net/lkddb/web-lkddb/NUMA.html which says: >>> Enable NUMA (Non-Uniform Memory Access) support. >>> The kernel will try to allocate memory used by a CPU on the local >>> memory controller of the CPU and add some more NUMA awareness to the >>> kernel. >> >> Clearly CONFIG_NUMA enables memory awareness, but there's no >> indication in the description whether information about the NUMA >> physical architecture is 'hidden', or whether it is still exposed >> through /sys/devices/system/node* (which is used by the rte >> initialisation code to determine how many sockets there are). >> Unfortunately, I don't have ready access to a multi-socket Linux >> system that I can test this out on, so I took the conservative >> approach that it may be possible to have CONFIG_NUMA disabled, but >> the kernel still report more than one node, and coded the change to >> generate a debug message if this occurs. >> >> Do you know whether CONFIG_NUMA turns off all knowledge about the >> hardware architecture?  If it does, then I agree that the test for >> rte_socket_count() serves no purpose and should be removed. >> > > I have a system with a custom compiled kernel, i can recompile it > without this flag and test this. I'll report back with results :) >