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 58DF8A04B7; Thu, 17 Sep 2020 15:05:48 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B88911C128; Thu, 17 Sep 2020 15:05:47 +0200 (CEST) Received: from mail-wm1-f68.google.com (mail-wm1-f68.google.com [209.85.128.68]) by dpdk.org (Postfix) with ESMTP id C950E1C10F for ; Thu, 17 Sep 2020 15:05:46 +0200 (CEST) Received: by mail-wm1-f68.google.com with SMTP id y15so1984485wmi.0 for ; Thu, 17 Sep 2020 06:05:46 -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=aqZAkl5xmIBf+/MrHnUpj49Uvwv29eTR4K25BpkDuRhx9h7OpI34DNlqMbmrWM0R9A Lo2vpWJN9ASoG+WfhLDV5TYH9KXLFvrgVi+oCqiXWBBBXytlBHn6BfOwHUEJki4pLG3i z1pJReXnBvvXQ2Fyga7i+H3FIKx1OrriA3kmoVPmrXjJo/fN+HtbAqriVxIdArABKuqT ugD7Ao7Hfu3GOJHKlyat+56jbmyIXWjnp0mYYira/rORTBbevFn0uKgoOFrlv88Q0mKY tj8DApek90WzU/OHpvyy4xDFkq5GE1A1ggs1/Zx0J2hwAddigeY6zFTEcvdbZAxLFiFC SLIw== X-Gm-Message-State: AOAM533zCVWjE28mX6aEgsxQBFs2RIb7PIcWdAJudwjGYV7PGNZLUDbB z97XHyW6PY49zOa1OCbyHe0H3Q== 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-dev] [PATCH] mem: fix allocation failure on non-NUMA kernel X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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 :) >