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 10475A053A; Wed, 5 Aug 2020 16:36:37 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 53DB12C23; Wed, 5 Aug 2020 16:36:37 +0200 (CEST) Received: from mail-wr1-f65.google.com (mail-wr1-f65.google.com [209.85.221.65]) by dpdk.org (Postfix) with ESMTP id 495332BF2 for ; Wed, 5 Aug 2020 16:36:36 +0200 (CEST) Received: by mail-wr1-f65.google.com with SMTP id f7so40970911wrw.1 for ; Wed, 05 Aug 2020 07:36:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind.com; s=google; h=reply-to:subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=1d6Ljs2KOSPQpHJE2AdKi+ILLN+pq1KnOuqtrlg32FE=; b=LYiuV/eQTU+1YRa10CzLexF7f58aS5bxc6xRHWGbVz+cxGiR3KKv5dby7QXlU+1jqj rQVLiZn6dblb95x2s0w8Dh6A0sWVhA8k3YLsoueTLo7dC6kTy5NU+vgokwPCr4GP1tvx RBn7AXYFuZWvDjwO9lXI7ZkBjT23LUorWkB9Kk56oBI/QYHZOiD8+GqShWIHGTAJqEWS jV/3m+LyoIol0U7GQbZ2jAfIfjogMD0YOCyyoHYIYxecKcCNeNcjmmFb3mG6CEM6QvMG qZv3HppGMKLHilsTxp3RIEZBQJviDsgN3UbCDqA3mmx49AF6DEhUl4+pXKevkhWqEFkb ndTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:reply-to:subject:to:cc:references:from :organization:message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=1d6Ljs2KOSPQpHJE2AdKi+ILLN+pq1KnOuqtrlg32FE=; b=ITtuRoi5to4oBX7Ytb+Dos4ddaqDgApuO95sRJfPpOdNPZFUNZTFOv21wKGVoS5r5L qzRDZSksOK9PeE0PMYiX88DSmI4kCu8SUZHbwG2vsRgwUaRuF8w/8vkHaimD9dIzWnfv obuSezOZGmuOxLR/5FRh1uuWTE9/ZXFl/fPkm4TDq0hOXZrE3rubaGOnWMMrP4Xrvo+7 lDCj9WjosnPtzB9ebbab7qkn52uWxqpPc5xrPm4nLzRbKD80DTmEwgfiOTpN0YgcRJPk 9dK2wNU4wvC0XQSBYnPLyprWIDB3CpjEqGeZjFvq7Iu5IoIdEq5X/NLcVo+czr+jq/Sz yLfw== X-Gm-Message-State: AOAM530tc/vbqx3Ilr9/RR5HY6Iusihw1oAWB05dErnRvCMoAd7bfAkO fi3SuCheBcgyhy0ZB16emxHS+A== X-Google-Smtp-Source: ABdhPJzjvf6r5O1PlvcwG8B2pAnAlfv8gRVKcYqnmnhbZxEXbnngJ62h9+hLr0B09JCQZf8jPRxV/Q== X-Received: by 2002:adf:ef08:: with SMTP id e8mr3280408wro.164.1596638195866; Wed, 05 Aug 2020 07:36:35 -0700 (PDT) Received: from ?IPv6:2a01:e0a:410:bb00:1829:7379:df21:bd9? ([2a01:e0a:410:bb00:1829:7379:df21:bd9]) by smtp.gmail.com with ESMTPSA id y142sm3246152wmd.3.2020.08.05.07.36.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 05 Aug 2020 07:36:34 -0700 (PDT) To: Nick Connolly , Anatoly Burakov Cc: dev@dpdk.org, stable@dpdk.org References: <20200805122640.13884-1-nick.connolly@mayadata.io> <4a1d578d-30e3-88de-be02-34ee0dd41ad1@mayadata.io> From: Nicolas Dichtel Organization: 6WIND Message-ID: <906edd92-cda3-9e79-ebdd-29a944082b61@6wind.com> Date: Wed, 5 Aug 2020 16:36:33 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <4a1d578d-30e3-88de-be02-34ee0dd41ad1@mayadata.io> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit 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 Reply-To: nicolas.dichtel@6wind.com List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Le 05/08/2020 à 16:20, Nick Connolly a écrit : [snip] >>> Fixes: 2a96c88be83e ("mem: ease init in a docker container") >> I'm wondering if the bug existed before this commit. >> >> Before this commit, it was: >>         move_pages(getpid(), 1, &addr, NULL, &cur_socket_id, 0); >>         if (cur_socket_id != socket_id) { >>                 /* error */ >> >> Isn't it possible to hit this error case if CONFIG_NUMA is unset in the kernel? > I've just run the previous code to test this out and you are right that > move_pages does indeed return -1 with errno set to ENOSYS, but nothing checks > this so execution carries on and compares cur_socket_id (which will be unchanged > from the zero initialization) with socket_id (which is presumably also zero), > thus allowing the allocation to succeed! I came to this conclusion, but I didn't check if socket_id could be != from 0. >> [snip] >>> +    if (check_numa()) { >>> +        ret = get_mempolicy(&cur_socket_id, NULL, 0, addr, >>> +                    MPOL_F_NODE | MPOL_F_ADDR); >>> +        if (ret < 0) { >>> +            RTE_LOG(DEBUG, EAL, "%s(): get_mempolicy: %s\n", >>> +                __func__, strerror(errno)); >>> +            goto mapped; >>> +        } else if (cur_socket_id != socket_id) { >>> +            RTE_LOG(DEBUG, EAL, >>> +                    "%s(): allocation happened on wrong socket (wanted %d, >>> got %d)\n", >>> +                __func__, socket_id, cur_socket_id); >>> +            goto mapped; >>> +        } >>> +    } else { >>> +        if (rte_socket_count() > 1) >>> +            RTE_LOG(DEBUG, EAL, "%s(): not checking socket for allocation >>> (wanted %d)\n", >>> +                    __func__, socket_id); >> nit: maybe an higher log level like WARNING? > Open to guidance here - my concern was that this is going to be generated for > every call to alloc_seg() and I'm not sure what the frequency will be - I'm > cautious about flooding the log with warnings under 'normal running'.  Are the > implications of running on a multi socket system with NUMA support disabled in > the kernel purely performance related for the DPDK or is there a functional > correctness issue as well? Is it really a 'normal running' to have CONFIG_RTE_EAL_NUMA_AWARE_HUGEPAGES in dpdk and not CONFIG_NUMA in the kernel? Regards, Nicolas