All of lore.kernel.org
 help / color / mirror / Atom feed
From: Willy Tarreau <w@1wt.eu>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Ben Greear <greearb@candelatech.com>, netdev <netdev@vger.kernel.org>
Subject: Re: TCP many-connection regression between 4.7 and 4.13 kernels.
Date: Mon, 22 Jan 2018 19:27:37 +0100	[thread overview]
Message-ID: <20180122182737.GA18218@1wt.eu> (raw)
In-Reply-To: <1516644966.3478.10.camel@gmail.com>

Hi Eric,

On Mon, Jan 22, 2018 at 10:16:06AM -0800, Eric Dumazet wrote:
> On Mon, 2018-01-22 at 09:28 -0800, Ben Greear wrote:
> > My test case is to have 6 processes each create 5000 TCP IPv4 connections to each other
> > on a system with 16GB RAM and send slow-speed data.  This works fine on a 4.7 kernel, but
> > will not work at all on a 4.13.  The 4.13 first complains about running out of tcp memory,
> > but even after forcing those values higher, the max connections we can get is around 15k.
> > 
> > Both kernels have my out-of-tree patches applied, so it is possible it is my fault
> > at this point.
> > 
> > Any suggestions as to what this might be caused by, or if it is fixed in more recent kernels?
> > 
> > I will start bisecting in the meantime...
> > 
> 
> Hi Ben
> 
> Unfortunately I have no idea.
> 
> Are you using loopback flows, or have I misunderstood you ?
> 
> How loopback connections can be slow-speed ?

A few quick points : I have not noticed this on 4.9, which we use with
pretty satisfying performance (typically around 100k conn/s). However
during some recent tests I did around the meltdown fixes on 4.15, I
noticed a high connect() or bind() cost to find a local port when
running on the loopback, that I didn't have the time to compare to
older kernels. However, strace clearly showed that bind() (or connect()
if bind was not used) could take as much as 2-3 ms as source ports were
filling up.

To be clear, it was just a quick observation and anything could be wrong
there, including my tests. I'm just saying this in case it matches anything
Ben has observed. I can try to get more info if that helps, but it could be
a different case.

Cheers,
Willy

  reply	other threads:[~2018-01-22 18:27 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-22 17:28 TCP many-connection regression between 4.7 and 4.13 kernels Ben Greear
2018-01-22 18:16 ` Eric Dumazet
2018-01-22 18:27   ` Willy Tarreau [this message]
2018-01-22 18:30   ` Ben Greear
2018-01-22 18:44     ` Ben Greear
2018-01-22 18:46     ` Josh Hunt
2018-01-23 22:06       ` Ben Greear
2018-01-23 21:49   ` TCP many-connection regression (bisected to 4.5.0-rc2+) Ben Greear
2018-01-23 22:07     ` Eric Dumazet
2018-01-23 22:09       ` Ben Greear
2018-01-23 22:29         ` Eric Dumazet
2018-01-23 23:10           ` Ben Greear
2018-01-23 23:21             ` Eric Dumazet
2018-01-23 23:27               ` Ben Greear
2018-01-24  0:05                 ` Ben Greear

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=20180122182737.GA18218@1wt.eu \
    --to=w@1wt.eu \
    --cc=eric.dumazet@gmail.com \
    --cc=greearb@candelatech.com \
    --cc=netdev@vger.kernel.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.