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 5699AA0093 for ; Tue, 19 May 2020 14:58:50 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 4DE841C1E4; Tue, 19 May 2020 14:58:50 +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 50B431C1E4 for ; Tue, 19 May 2020 14:58:49 +0200 (CEST) Received: by mail-wm1-f67.google.com with SMTP id z72so3455644wmc.2 for ; Tue, 19 May 2020 05:58:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=Rtyf5G8gXaQOoi7iGmRlDXx65fZf9SlDzuB5flZD10Y=; b=Cm9wZ+3V341q2QWRtgf55po/YiFPOiPX3aTTWBDN3GUl/vzwEaAPrwpNp4fuHe/p23 JPNkC+16mbqnKVmDjO3GCfuHSVioASbGHOO/ypyQujxP7q1a17dVGtCbw7dwyPbgrJ4M slp3Hyw7IXpBF9kCLowAoS7gro/2La/hHgZDFUcJbDzvqPu61C2qs1CjPdH68+efkcdQ puIMHpqbangoceFca7smbXqqK+/cAFy+4xtLXOiNBf8ALtmd44UwIxYjz7EWvtWeQQGV yuq6iR4dzoo4/kSHc4bE36K/xyp7IrryMdwFbWcfGid/8lqvVSSSi/HT0TnpSzRFadbV ZHMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=Rtyf5G8gXaQOoi7iGmRlDXx65fZf9SlDzuB5flZD10Y=; b=Ayg+BtIbTILg2nUtggkhp5l68K8zYrOYHdAQCqk80HIzFkWS2iR2gNmvlTvse4OzqZ Mx42iuJlSx5E9iFWtJGvkDfFLxiEQgYQ/bMU7DbdDPUiTvJjiOzJLtWQjQZb2Wa3CHRU 71dZetNEtipNTK3ddlsxbT35+3CLV4C6/mw3Qh5Uoa5W/aPV7HMpb3owGp66XASYehe+ wCA5k8hgh9n2B3c1VWm490ClmWlYsf7z4vPjzowmuXCMmYTHHw9e10ihaSpMNgaWvImY ARrAs3UqhObgNcsF9hDWy5HENP2zi4a+y+7tAOAhUYOCjdm93QacxUIgYiSWP5R37m8C TlxQ== X-Gm-Message-State: AOAM5300ajUcsCVjqC/smuAr+glV4fPELF9qT2nOYqQiFldhKD2j479s ivKu5OBSogouhcKZ7LdpT1W0u4UMK3V+MA== X-Google-Smtp-Source: ABdhPJxZUvnV0Ol7/cY1+LVCrhTFn47wIUFwIqxp76YaBdg/L8DNxMXGQtv8YnIT/OfA5ZXpqYVbJA== X-Received: by 2002:a1c:23d2:: with SMTP id j201mr5526818wmj.48.1589893129059; Tue, 19 May 2020 05:58:49 -0700 (PDT) Received: from localhost ([88.98.246.218]) by smtp.gmail.com with ESMTPSA id 94sm21193264wrf.74.2020.05.19.05.58.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 May 2020 05:58:48 -0700 (PDT) From: luca.boccassi@gmail.com To: David Marchand Cc: Andrea Arcangeli , Maxime Coquelin , Aaron Conole , Anatoly Burakov , dpdk stable Date: Tue, 19 May 2020 13:53:21 +0100 Message-Id: <20200519125804.104349-11-luca.boccassi@gmail.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20200519125804.104349-1-luca.boccassi@gmail.com> References: <20200519125804.104349-1-luca.boccassi@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: [dpdk-stable] patch 'mem: mark pages as not accessed when reserving VA' has been queued to stable release 19.11.3 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" Hi, FYI, your patch has been queued to stable release 19.11.3 Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable yet. It will be pushed if I get no objections before 05/21/20. So please shout if anyone has objections. Also note that after the patch there's a diff of the upstream commit vs the patch applied to the branch. This will indicate if there was any rebasing needed to apply to the stable branch. If there were code changes for rebasing (ie: not only metadata diffs), please double check that the rebase was correctly done. Thanks. Luca Boccassi --- >From d0e456e9b1af8594ed22382e33bc6e1d5acec994 Mon Sep 17 00:00:00 2001 From: David Marchand Date: Mon, 9 Mar 2020 15:54:42 +0100 Subject: [PATCH] mem: mark pages as not accessed when reserving VA [ upstream commit 8a4baf06c17a806696fb10aba36fce7471983028 ] When the memory allocator reserves virtual addresses, it still does not know what they will be used for. Besides, huge areas are reserved for memory hotplug in multiprocess setups. But most of the pages are unused in the whole life of the processes. Change protection mode to PROT_NONE when only reserving VA. The memory allocator already switches to the right mode when making use of it. It also has the nice effect of getting those pages skipped by the kernel when calling mlockall() or when a coredump gets generated. Suggested-by: Andrea Arcangeli Signed-off-by: David Marchand Reviewed-by: Maxime Coquelin Acked-by: Aaron Conole Acked-by: Anatoly Burakov --- lib/librte_eal/common/eal_common_memory.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/librte_eal/common/eal_common_memory.c b/lib/librte_eal/common/eal_common_memory.c index 4a9cc1f19a..cc7d54e0c7 100644 --- a/lib/librte_eal/common/eal_common_memory.c +++ b/lib/librte_eal/common/eal_common_memory.c @@ -97,7 +97,7 @@ eal_get_virtual_area(void *requested_addr, size_t *size, return NULL; } - mapped_addr = mmap(requested_addr, (size_t)map_sz, PROT_READ, + mapped_addr = mmap(requested_addr, (size_t)map_sz, PROT_NONE, mmap_flags, -1, 0); if (mapped_addr == MAP_FAILED && allow_shrink) *size -= page_sz; -- 2.20.1 --- Diff of the applied patch vs upstream commit (please double-check if non-empty: --- --- - 2020-05-19 13:56:19.274078176 +0100 +++ 0011-mem-mark-pages-as-not-accessed-when-reserving-VA.patch 2020-05-19 13:56:18.175501026 +0100 @@ -1,8 +1,10 @@ -From 8a4baf06c17a806696fb10aba36fce7471983028 Mon Sep 17 00:00:00 2001 +From d0e456e9b1af8594ed22382e33bc6e1d5acec994 Mon Sep 17 00:00:00 2001 From: David Marchand Date: Mon, 9 Mar 2020 15:54:42 +0100 Subject: [PATCH] mem: mark pages as not accessed when reserving VA +[ upstream commit 8a4baf06c17a806696fb10aba36fce7471983028 ] + When the memory allocator reserves virtual addresses, it still does not know what they will be used for. Besides, huge areas are reserved for memory hotplug in multiprocess @@ -16,8 +18,6 @@ It also has the nice effect of getting those pages skipped by the kernel when calling mlockall() or when a coredump gets generated. -Cc: stable@dpdk.org - Suggested-by: Andrea Arcangeli Signed-off-by: David Marchand Reviewed-by: Maxime Coquelin