linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Kernel.org Bugbot" <bugbot@kernel.org>
To: linux-fsdevel@vger.kernel.org, viro@zeniv.linux.org.uk,
	bugs@lists.linux.dev, brauner@kernel.org, willy@infradead.org
Subject: Re: large pause when opening file descriptor which is power of 2
Date: Fri, 28 Apr 2023 00:37:40 +0000 (UTC)	[thread overview]
Message-ID: <20230428-b217366c9-e84e92b8b016@bugzilla.kernel.org> (raw)
In-Reply-To: <ZEq8iSl985aqEy4+@casper.infradead.org>

phemmer+kernel writes via Kernel.org Bugzilla:

(In reply to Bugbot from comment #8)
> Matthew Wilcox <willy@infradead.org> replies to comment #6:
> 
> On Wed, Apr 26, 2023 at 11:42:01PM +0000, Kernel.org Bugbot wrote:
> > Yes. I'm using using sockets for IPC. Specifically haproxy with its
> > SPOE protocol. Low latency is important. Normally a call (including
> > optional connect if a new connection is needed) will easily complete
> > in under 100us. So I want to set a timeout of 1ms to avoid blocking
> > traffic. However because this issue effectively randomly pops up,
> > that 1ms timeout is too low, and the issue can actually impact
> > multiple in-flight requests because haproxy tries to share that one
> > IPC connection for them all. But if I raise the timeout (and I'd have
> > to raise it to something like 100ms, as I've seen delays up to 47ms in
> > just light testing), then I run the risk of significantly impacting
> > traffic if there is a legitimate slowdown. While a low timeout and
> > the occasional failure is probably the better of the two options,
> > I'd prefer not to fail at all.
> 
> A quick workaround for this might be to use dup2() to open a newfd
> that is larger than you think your process will ever use.  ulimit -n
> is 1024 (on my system), so choosing 1023 might be a good idea.
> It'll waste a little memory, but ensures the fd array will never need to
> expand.

That's a good idea. I was originally considering opening a bunch of file descriptors one by one. But if it will grow even while skipping all the FDs in between, then that seems like it should work. At least for the app which I control. I don't know that it'd be a welcome change on the haproxy side though. And both sides would need it to completely alleviate the issue.

View: https://bugzilla.kernel.org/show_bug.cgi?id=217366#c9
You can reply to this message to join the discussion.
-- 
Deet-doot-dot, I am a bot.
Kernel.org Bugzilla (peebz 0.1)


      reply	other threads:[~2023-04-28  0:37 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-26 17:58 large pause when opening file descriptor which is power of 2 Kernel.org Bugbot
2023-04-26 19:13 ` Matthew Wilcox
2023-04-26 19:46   ` Al Viro
2023-04-26 19:56     ` Matthew Wilcox
2023-04-26 20:33       ` Al Viro
2023-04-26 19:58     ` Al Viro
2023-04-26 23:42   ` Kernel.org Bugbot
2023-04-27  9:28     ` Christian Brauner
2023-04-27 18:18     ` Matthew Wilcox
2023-04-28  0:37       ` Kernel.org Bugbot [this message]

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=20230428-b217366c9-e84e92b8b016@bugzilla.kernel.org \
    --to=bugbot@kernel.org \
    --cc=brauner@kernel.org \
    --cc=bugs@lists.linux.dev \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=willy@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).