From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 9371AA00C2; Thu, 6 Oct 2022 12:42:25 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3386A42BF0; Thu, 6 Oct 2022 12:42:25 +0200 (CEST) Received: from mail-lj1-f173.google.com (mail-lj1-f173.google.com [209.85.208.173]) by mails.dpdk.org (Postfix) with ESMTP id 623D342B70 for ; Thu, 6 Oct 2022 12:42:24 +0200 (CEST) Received: by mail-lj1-f173.google.com with SMTP id t16so1755924ljh.3 for ; Thu, 06 Oct 2022 03:42:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date; bh=eqTiKekYBHwvaTbuQe9Qvn6ZDS1N4sLZ83E8lAk6l/U=; b=Liblce+mvrcRQyb+2atuSSa0cPXZjZro8wGWI7Zsv4LNDl4pew/kXRbQ2MW6aUCDOC SBpN/4xXvJ16gUeD1Q08q6s3LswAyOvRxqbf87bhCKgEVDdtWCY5Fy7Nr1VLgzRN5dE9 PNe5u0MHdVVRchYX7rPCLlz0X+d+9yL1vfEPgdbaHcmXWkTNr9jnQ/HThMV6UOsmPzzC BqOFAf7WrC4GTLAnuASB9nWYgXX0Xbfw6DMEpD/o7PaFfH6ZeEqCO6K4FQY9w2dYfURs ReM4UkzqDKRl8MVRQ7CTN7RF6R4aav0q9wFMaQpj7JRjxBLaz6w+9RtkeiNfslyx7hAa AdbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date; bh=eqTiKekYBHwvaTbuQe9Qvn6ZDS1N4sLZ83E8lAk6l/U=; b=xPncsOkK+r7tAWl7+CT5R5g/GE/7XVc/aJJEJFrAiLHYNvw47D1yDn1oBtOmk5Xmbt t38Tfzo2sg3CgwzZQH2+SARElm5i1kzWF4JZLzOWubkk7i9yNbqKOxbFQhLYiUPhu81S o0hL8JA/ooN5MgM7kx/twvzhPT9JGJlhiLuOrmCylhRuM1AoygObQfgM40uI34XmPklP HLBzsOUyyEj47CSHY2k4pl0/lydwP7UsQuSgPovStiP6cwDhd3s/PjZ+dflCgCZDjGo+ 5s7a/RWBd2BTHhahQ3n5HYZV8EdMjEcCJ9Zx3nsroKfMo5McFy8pP+KL3n08OQNHaXTr FedQ== X-Gm-Message-State: ACrzQf1OwdSzMaRs8Fh3FdgpPEl+BpEbk/K62Exv+F3hXU91LKeTlYW9 BlnH5HHFFHwfb64LqvIF8Ys= X-Google-Smtp-Source: AMsMyM7lSvpNUulR9HO9Ta6kUQuOAn8/ZW6Nljxul6jJM0+TQoeANhF22h42VlwCCQ2VVVspdZjDQQ== X-Received: by 2002:a05:651c:338:b0:26d:e667:d769 with SMTP id b24-20020a05651c033800b0026de667d769mr1489808ljp.254.1665052943750; Thu, 06 Oct 2022 03:42:23 -0700 (PDT) Received: from sovereign (broadband-37-110-65-23.ip.moscow.rt.ru. [37.110.65.23]) by smtp.gmail.com with ESMTPSA id h13-20020a056512220d00b00492e6642937sm2641042lfu.200.2022.10.06.03.42.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Oct 2022 03:42:23 -0700 (PDT) Date: Thu, 6 Oct 2022 13:42:22 +0300 From: Dmitry Kozlyuk To: "huzaifa.rahman" Cc: anatoly.burakov@intel.com, dev@dpdk.org, stephen@networkplumber.org Subject: Re: [PATCH] mem: close rtemap files Message-ID: <20221006134222.35ed51e1@sovereign> In-Reply-To: <20221006100405.2809898-1-huzaifa.rahman@emumba.com> References: <20221006100405.2809898-1-huzaifa.rahman@emumba.com> X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 2022-10-06 10:04 (UTC+0000), huzaifa.rahman: > Bugzilla ID: 560 > > The memory subsystem is leaving open a file descriptor for each > rtemap file. This can lead to hundreds of extra open file descriptors > which has negative side effects. For example, the application may go > over its maximum file descriptor limit, or the application may be using > limited API's like select that only allow 1024 file descriptors. > > The EAL memory subsystem does not need to hold the file open. > Probably the original intention was to keep the file locked, but that is > not necessary. The Linux kernel keeps a reference count on the file, > and the mmap counts is a reference and therefore maintains the file > as locked. > > The fix is just to close the file after it is setup. > > Signed-off-by: huzaifa.rahman > --- > lib/eal/linux/eal_memalloc.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/lib/eal/linux/eal_memalloc.c b/lib/eal/linux/eal_memalloc.c > index f8b1588cae..955c4e4f95 100644 > --- a/lib/eal/linux/eal_memalloc.c > +++ b/lib/eal/linux/eal_memalloc.c > @@ -679,6 +679,9 @@ alloc_seg(struct rte_memseg *ms, void *addr, int socket_id, > > huge_recover_sigbus(); > > + close(fd); > + fd_list[list_idx].fds[seg_idx] = -1; > + > ms->addr = addr; > ms->hugepage_sz = alloc_sz; > ms->len = alloc_sz; This breaks rte_memseg_get_fd(). If memfd_create() was used to open the file descriptor, there seems no way to reopen it once closed. --single-file-segments may be used to save FD count, does using it solve your issue?