phemmer+kernel writes via Kernel.org Bugzilla: (In reply to Bugbot from comment #8) > Matthew Wilcox <willy@xxxxxxxxxxxxx> 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)
