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 0D5A8A0548; Thu, 20 Oct 2022 12:46:36 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id EAC6042C80; Thu, 20 Oct 2022 12:46:35 +0200 (CEST) Received: from mail-lf1-f47.google.com (mail-lf1-f47.google.com [209.85.167.47]) by mails.dpdk.org (Postfix) with ESMTP id 7D54C42C7C for ; Thu, 20 Oct 2022 12:46:35 +0200 (CEST) Received: by mail-lf1-f47.google.com with SMTP id o12so24369575lfq.9 for ; Thu, 20 Oct 2022 03:46:35 -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 :message-id:reply-to; bh=uNGoyRmK+C2KbkR+3e26WpnoGu5D7dcC/eHL5UslnJ4=; b=pS1Ohsgx49lkO27mh01wikJ7EV7YJC0AJthzeNX/pGRnBU1XrPwxW0YwJVl4SSfIkk djov1OeDqUX5bq4nqu55UJPRC/hK/xj/So31R43dSWOdIBWo2RE504Cjod/+LlePZ49F frMghfHpAof7cdSLoJeRAsTn3+vO7FToO1pK1B/nM/LL/g4Lb6t5anXQw2m9gZsubB8V sshjd5JVlPoAoiLr3P5jTsKpST2NaZOpjgk+1ZixAskTb2/K/0hrXaFg/K9+h322MXSK UYiupRKj0Ja/8Onx1AWlVRPKt+PbcCXjV43pe05LoLzj9u3MV9gBMNq3TX8ljWLuIT0w 1tGQ== 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:message-id:reply-to; bh=uNGoyRmK+C2KbkR+3e26WpnoGu5D7dcC/eHL5UslnJ4=; b=NvQUUBIsVi2eODUWU0hCde4yF2/kbdChRFZUK/6Ppe8yYewH3i47v5jmsPOQJVPpk4 xQjrTAWiSBjvLiQZnUwHoYBJpRDrI1vCFcAvkDByanMgq71UhaRqYkR09mG1Dh9205tR Z1sJSSQWh1REUPoHTTK8P4PsFVNC9pH3Z0Oeod61XusOxn0lu8hBjHs+rxtpPYHpfm2V DtymVcYZO6LtDXfE+JSaoS4/doz3wXWbpzqUrbcnb1HKWbvAdhDRBpceA9FuAXyKtq7X buYGPqEuRIB3f+Kk0+zA+5kzTrkWFx3QuRU6i7NBr3CX7uFQX/ul/9iex6Fz/+GM5WbI nGeQ== X-Gm-Message-State: ACrzQf1gO6XRibHwPk3BVGszm1Zc1sYZEOsFcBJtc5UkGUNj2ehn3Mvj HxS/f350OgYk033MsO0SJy4= X-Google-Smtp-Source: AMsMyM6gCgvCldbJKOd0TKZVP5FXMjDlWqOMzDqWsuzDOMTspKvz/W3uNU1Juuw55LLRhOy/FcsiOQ== X-Received: by 2002:a05:6512:3190:b0:4a2:a0d5:e71d with SMTP id i16-20020a056512319000b004a2a0d5e71dmr4228378lfe.200.1666262794814; Thu, 20 Oct 2022 03:46:34 -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 r3-20020a2ea383000000b0026faf7bfa62sm2845862lje.76.2022.10.20.03.46.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 20 Oct 2022 03:46:34 -0700 (PDT) Date: Thu, 20 Oct 2022 13:46:33 +0300 From: Dmitry Kozlyuk To: Huzaifa Rahman Cc: anatoly.burakov@intel.com, dev@dpdk.org, stephen@networkplumber.org, Thomas Monjalon , Bruce Richardson , David Marchand Subject: Re: [PATCH] mem: close rtemap files Message-ID: <20221020134633.03c5aa5c@sovereign> In-Reply-To: References: <20221006100405.2809898-1-huzaifa.rahman@emumba.com> <20221006134222.35ed51e1@sovereign> 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-20 15:12 (UTC+0500), Huzaifa Rahman: > On Thu, Oct 6, 2022 at 3:42 PM Dmitry Kozlyuk > wrote: > > > 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? > > > yes, It reduces the opened files from 450 to 2. > Is there any down side of using --single-file-segments flag. Because if > this is better why not make it the default behaviour. Single-file segments option needs fallocate() kernel support to release pages to the kernel (see `resize_hugefile_in_filesystem` function). I wonder if DPDK still targets Linux/FreeBSD versions that lack this support. If not, I don't see an issue in changing the behavior and removing the option. Only it may be too late in this release and the change is a breaking one. Adding some people who might know more about DPDK usage. P.S. Moved the reply to the bottom to keep context.