All of lore.kernel.org
 help / color / mirror / Atom feed
From: Huzaifa Rahman <huzaifa.rahman@emumba.com>
To: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
Cc: anatoly.burakov@intel.com, dev@dpdk.org, stephen@networkplumber.org
Subject: Re: [PATCH] mem: close rtemap files
Date: Thu, 20 Oct 2022 15:12:58 +0500	[thread overview]
Message-ID: <CANVhzTjbshcM8qvcBNideuZi6Y-p16hx+oMitT=sE3r0PDUT7Q@mail.gmail.com> (raw)
In-Reply-To: <20221006134222.35ed51e1@sovereign>

[-- Attachment #1: Type: text/plain, Size: 1939 bytes --]

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 <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
> > 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 <huzaifa.rahman@emumba.com>
> > ---
> >  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?
>

[-- Attachment #2: Type: text/html, Size: 2582 bytes --]

  reply	other threads:[~2022-10-20 10:13 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-06 10:04 [PATCH] mem: close rtemap files huzaifa.rahman
2022-10-06 10:42 ` Dmitry Kozlyuk
2022-10-20 10:12   ` Huzaifa Rahman [this message]
2022-10-20 10:46     ` Dmitry Kozlyuk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CANVhzTjbshcM8qvcBNideuZi6Y-p16hx+oMitT=sE3r0PDUT7Q@mail.gmail.com' \
    --to=huzaifa.rahman@emumba.com \
    --cc=anatoly.burakov@intel.com \
    --cc=dev@dpdk.org \
    --cc=dmitry.kozliuk@gmail.com \
    --cc=stephen@networkplumber.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.