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 ACC10A04BB for ; Thu, 17 Sep 2020 16:19:23 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 816981D683; Thu, 17 Sep 2020 16:19:23 +0200 (CEST) Received: from mail-wm1-f67.google.com (mail-wm1-f67.google.com [209.85.128.67]) by dpdk.org (Postfix) with ESMTP id 021241D664 for ; Thu, 17 Sep 2020 16:19:21 +0200 (CEST) Received: by mail-wm1-f67.google.com with SMTP id k18so2238631wmj.5 for ; Thu, 17 Sep 2020 07:19:20 -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=W0cl2x1pMWllEfrvkgwB0N54DTidKegrbou3MiNgnCY=; b=NYX1V3FG3E6ItjK1eRiqNQQDEus7kEWCknfK+gMk9QjGJMw7Ku5rDUtZddm+ARQUYu ebR72fapJ1lduQfc0OoRCtxdyLKWsT6xfkQCELVLcC2dTC5AKR/DwD05+26JS2nsAWct d4AXX0YQf96CLcZtFqf2J2uKJrenF6qY+64F6OiYikkrHxyVEv9rxqD5Sf7e4w0cjGos sjNl7Owo9MyitQwc4ySjYX5SSOiT3KQNf+cDIow2WLZjcb72yEyO+r5HY+D5bpjC6JT0 2a+eyzwVqcpYladzNUSXTgrZ5BrRM9SLUpK5Dj+7PICXtCYl/3tTu+umjuP0NIkZxm1i N8Ag== 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=W0cl2x1pMWllEfrvkgwB0N54DTidKegrbou3MiNgnCY=; b=dcn+8mD7uvj5NVo64pz8U9qYfqv+o9LoeZzfFEfopNd2EW3XBTlvAEI9ES9wcvXvI2 l315pwYJAzY/hsTibeoYRQQ5yo5KnhxaQQCN15kp2IyWxKeF9V46zxK3wmG0Lbiofs62 aeRI+W2ifHAS9Da1v7dedC+x/pm0oWyfPJ8NyANEwKHhA1xy0chXmcTEzMK8LbJXOSzM RW3f82F7fA+NmfxtEo48hLHywbIF7NaJBNhsn5n7pLFEiP8wRTEDWVk5yuoFvfyBPsxY jaUhV/3kZSjCVBIJ5OTAfnhHHvV8xuDE1cezhc9TOjripwrfRpbFX54WFtDENSPZCWq4 GlVg== X-Gm-Message-State: AOAM532BJcuLGb68RlKK/t1bdn5q8bs4XYVEa12QFJ7sw382J65Ivj4K 5q2r2HAHWzY2zVHAUIuiShmrcHoh+uEGnw== X-Google-Smtp-Source: ABdhPJymJBNeGl53diqcJMNMhigjJA1+nuRd8YzA/ouFm1/wcJRA6U+IXgwnOPhWxgMbhoJ3eQ5Idw== X-Received: by 2002:a1c:4b13:: with SMTP id y19mr10077008wma.75.1600352360277; Thu, 17 Sep 2020 07:19:20 -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 n4sm38613070wrp.61.2020.09.17.07.19.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 17 Sep 2020 07:19:19 -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> <2ea114be-d606-229c-4fc0-bac06c0ea2fd@intel.com> <419f4946-958a-b166-07d0-a4df22cd2018@intel.com> Message-ID: <546e9840-68bd-1203-dbfe-32612c2bc01c@mayadata.io> Date: Thu, 17 Sep 2020 15:19:18 +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: <419f4946-958a-b166-07d0-a4df22cd2018@intel.com> 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" Sure. On 17/09/2020 15:18, Burakov, Anatoly wrote: > On 17-Sep-20 3:08 PM, Nick Connolly wrote: >> Excellent - thanks - I'll amend the patch. >> >> On 17/09/2020 15:07, Burakov, Anatoly wrote: >>> On 17-Sep-20 2:05 PM, Nick Connolly wrote: >>>> 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 :) >>>>> >>>> >>> >>> With CONFIG_NUMA set to 'n': >>> >>> [root@xxx ~]# find /sys -name "node*" >>> /sys/kernel/software_nodes/node0 >>> [root@xxx ~]# >>> >>> This is confirmed by running DPDK on that machine - i can see all >>> cores from all sockets, but they're all appearing on socket 0. So, >>> yes, that check isn't necessary :) >>> >> > > I would also add a comment explaining why we're checking for NUMA > support when NUMA support is defined at compiled time. >