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 BDC33A04BB; Thu, 17 Sep 2020 16:08:25 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 835781D664; Thu, 17 Sep 2020 16:08:24 +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 6F8DC1BEA1 for ; Thu, 17 Sep 2020 16:08:23 +0200 (CEST) Received: by mail-wm1-f68.google.com with SMTP id z9so2213008wmk.1 for ; Thu, 17 Sep 2020 07:08:23 -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=Ls0A/NPjZ0u4Uw213qNPfXwPlDvvegWFFOtboScnhM4=; b=H8IsrIhuxg9x6xOI9x382NRMFD5V+KyPH1+quP40BbdsVZdpDIj/cWRR+gFirtHlGW v47A4aKXoJZtoUxHHmJ0XwTM4UOCaiMHEs03q4WfjSAu7ilOkYhPpLf56+e75dK7o67s CegZXCdveD2rPAqfGxO0kLWqG1EcDTct+rBOW//LIxqNtc/5xp7B8Upv/l/zgSMWziFP MlYuTYQIpsGSgbV55LyoocVBKkg35wcPZB0Ek2gJa1KSDKw9TmcYbM+BDlhNzMRbTrK6 5ozmVOm/1zbOhXJlDNKqmAPp/DvfKrdyXkU+VZMWDf8avZlnX3mZzKAMktCammX/AhkY UFNA== 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=Ls0A/NPjZ0u4Uw213qNPfXwPlDvvegWFFOtboScnhM4=; b=b6PlSdeIAVmVUsc6HdhwAtNCf8726/kVuRsXD+ep1MHO2rThzPZr67v6kMjA2UbjC4 L2H2UZl8qRVsk4u2NHx+b0N5+fglLIISkIdbYTBBMwBuZPOBB6teugBnLaLT7qQa9u5F i1tnR15D6GrEQcc89lrhTe+YaBpCVWabmddAMdU5zZJnBel69TFk9F/6p8PSrBVcXDnV dR4oS576PWDtCFgGTDYFmk3vEQojvR3jo6o+Y3Rd1bOCeH1pVSXTliA0lreyHR8XV7aH GWoEsC2R5qnUMZyTtMYjexCuq4S4CXayuVAsqTASYoEge6j+whLACyZjO+3/JXZfcwhE gR1w== X-Gm-Message-State: AOAM533PZmgGQTIHHmtXT0mkderr8kTfcULoat3M+d/U4+Fo1XIG0J6s oDx05iLdTl1x6jhIXV5kDF0fiw== X-Google-Smtp-Source: ABdhPJyXUF0OwwvH+w3D6mgd6b8EJIq15F0efNcuCXhZzon0LzwUgvLjua+tzlT/xFCRRjKsjS5+Tw== X-Received: by 2002:a7b:c847:: with SMTP id c7mr10424259wml.149.1600351703049; Thu, 17 Sep 2020 07:08:23 -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 k4sm39385624wrx.51.2020.09.17.07.08.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 17 Sep 2020 07:08:21 -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> Message-ID: Date: Thu, 17 Sep 2020 15:08:20 +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: <2ea114be-d606-229c-4fc0-bac06c0ea2fd@intel.com> 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" 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 :) >