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 E8C06A04AF for ; Thu, 17 Sep 2020 14:57:49 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E13B91C128; Thu, 17 Sep 2020 14:57:49 +0200 (CEST) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 8BB9A1C128; Thu, 17 Sep 2020 14:57:48 +0200 (CEST) IronPort-SDR: glm73VGZtvzjok6F8sm3CZprMfsACVusYdJKNzy0fNii/jdI4JsD2vd7aFYZmG8v1V+1mIpj6B 7gijYWP++9zg== X-IronPort-AV: E=McAfee;i="6000,8403,9746"; a="159739822" X-IronPort-AV: E=Sophos;i="5.76,437,1592895600"; d="scan'208";a="159739822" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Sep 2020 05:57:47 -0700 IronPort-SDR: rwoCdT5iSrOm0qkiY67IxABfzhcWv18SbNZKAz49c8OwugsFwVlmd690l7gsi1/fBiUbLMYIsJ tgIK5Bpdj4Hg== X-IronPort-AV: E=Sophos;i="5.76,437,1592895600"; d="scan'208";a="483734974" Received: from aburakov-mobl.ger.corp.intel.com (HELO [10.213.206.43]) ([10.213.206.43]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Sep 2020 05:57:45 -0700 To: Nick Connolly 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> From: "Burakov, Anatoly" Message-ID: Date: Thu, 17 Sep 2020 13:57:43 +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: <8ebfbd1f-9a2b-3421-1d35-a3cf070ce8df@mayadata.io> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit 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" 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 :) -- Thanks, Anatoly