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 B2A19A0581; Thu, 20 Oct 2022 12:13:12 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A799742C80; Thu, 20 Oct 2022 12:13:12 +0200 (CEST) Received: from mail-lj1-f180.google.com (mail-lj1-f180.google.com [209.85.208.180]) by mails.dpdk.org (Postfix) with ESMTP id 974EC42C7C for ; Thu, 20 Oct 2022 12:13:10 +0200 (CEST) Received: by mail-lj1-f180.google.com with SMTP id c22so24344533lja.6 for ; Thu, 20 Oct 2022 03:13:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=emumba-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=tQnEXAplqQ3khJzMSp6p44um8dzi39uzyr51mirQmlU=; b=JvulQTXzHYlzm8U78X8W9BIu68miyd9IWbbJrfvNF989dLAzNSIXlEmXwdfwHyvwQn RiOu5QX0dlFtvstP1oBqAXybGQoc+KyXyMTPx/XbdB+MbaKZAfrPm2CgzugspKy5KgMT wP+ozjyBvXsDnSKyH1rQR8qgYWfiKg1LMHYZYdfyUwdbFVowUL7f7snBXOvJA0Rtk3+g y43wQ/SWdoeMZ58A1qpVoP4Jv0LofF2n1KOphR9HPJ5Czgs2S7hDQGfQ7tZpMbwknkjD 6GpDiEZ8+hkh57PKwA+pfbnm4Lhhv/+BnG8PmXXdpuNOZFhCbKxfLVShPylevXctdsYa Rj/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=tQnEXAplqQ3khJzMSp6p44um8dzi39uzyr51mirQmlU=; b=WKyKYV/XCMd0k0KAZP/MOahuPel8GrRO0fXRQBCwhJXbq5CWj73/UB8GsViMJ4GFkg 7cSUaweIBoGaeG/xq61CNA79GRu63CBVP9EzA705pkeXrQsMEhKN1dM6DoOviWCBDnzG CEOCfyUhzS1BzD8tpw3oTxrttnWGGt0gwwPGulO/Ja9x4CoWxHiS8gJ2riNDeMfofvhH hwF3r3xnhwz5SPiVfgcS0MBok5Ncp7hJr0ngt1GR5GX/NsY/gXb20vxs974i3IEse5Er aQ89wrgarpTTKU3n8zuDLm357syPRd58/Oj9NNiSfQ/T5RiVov77TK1/s0pXI3tcLeJn 1PNQ== X-Gm-Message-State: ACrzQf1/rXYPhTzR0etlG7lUnvoD9adJJRRqILHouRzewTlViJg7lT5o YP443CKgTMPzWjDtvDD0VPrYsHmPnumgXz1Vrq1RLw== X-Google-Smtp-Source: AMsMyM5pLlIysYeTl+Gt+/q07UTqcw0VXpKHMNZOiAiKdGr7Tl+8yhA7F9jxcHjsuM8d5kujIRvvYBgebRtI0GogwtA= X-Received: by 2002:a2e:2c14:0:b0:26f:ad18:55bf with SMTP id s20-20020a2e2c14000000b0026fad1855bfmr4578477ljs.42.1666260790133; Thu, 20 Oct 2022 03:13:10 -0700 (PDT) MIME-Version: 1.0 References: <20221006100405.2809898-1-huzaifa.rahman@emumba.com> <20221006134222.35ed51e1@sovereign> In-Reply-To: <20221006134222.35ed51e1@sovereign> From: Huzaifa Rahman Date: Thu, 20 Oct 2022 15:12:58 +0500 Message-ID: Subject: Re: [PATCH] mem: close rtemap files To: Dmitry Kozlyuk Cc: anatoly.burakov@intel.com, dev@dpdk.org, stephen@networkplumber.org Content-Type: multipart/alternative; boundary="0000000000007fe21305eb749218" 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 --0000000000007fe21305eb749218 Content-Type: text/plain; charset="UTF-8" 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. 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? > --0000000000007fe21305eb749218 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
yes, It reduces the opened files from 450 to 2.
Is the= re any down side of using --single-file-segments flag. Because if this is b= etter why not make it the default behaviour.

On Thu, Oct 6, 2022 at 3:= 42 PM Dmitry Kozlyuk <dmitry= .kozliuk@gmail.com> 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<= br> > which has negative side effects. For example, the application may go > over its maximum file descriptor limit, or the application may be usin= g
> 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 <huzaifa.rahman@emumba.com>
> ---
>=C2=A0 lib/eal/linux/eal_memalloc.c | 3 +++
>=C2=A0 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 s= ocket_id,
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0huge_recover_sigbus();
>=C2=A0
> +=C2=A0 =C2=A0 =C2=A0close(fd);
> +=C2=A0 =C2=A0 =C2=A0fd_list[list_idx].fds[seg_idx] =3D -1;
> +
>=C2=A0 =C2=A0 =C2=A0 =C2=A0ms->addr =3D addr;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0ms->hugepage_sz =3D alloc_sz;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0ms->len =3D 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?
--0000000000007fe21305eb749218--