From: "Prout, Andrew - LLSC - MITLL" <aprout@ll.mit.edu>
To: Christoph Paasch <christoph.paasch@gmail.com>,
Eric Dumazet <eric.dumazet@gmail.com>
Cc: "David S . Miller" <davem@davemloft.net>,
netdev <netdev@vger.kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jonathan Looney <jtl@netflix.com>,
Neal Cardwell <ncardwell@google.com>,
Tyler Hicks <tyhicks@canonical.com>,
Yuchung Cheng <ycheng@google.com>,
Bruce Curtis <brucec@netflix.com>,
Jonathan Lemon <jonathan.lemon@gmail.com>,
"Dustin Marquess" <dmarquess@apple.com>
Subject: RE: [PATCH net 2/4] tcp: tcp_fragment() should apply sane memory limits
Date: Wed, 10 Jul 2019 18:23:33 +0000 [thread overview]
Message-ID: <63cd99ed3d0c440185ebec3ad12327fc@ll.mit.edu> (raw)
In-Reply-To: <CALMXkpZ4isoXpFp_5=nVUcWrt5TofYVhpdAjv7LkCH7RFW1tYw@mail.gmail.com>
On 6/17/19 8:19 PM, Christoph Paasch wrote:
>
> Yes, this does the trick for my packetdrill-test.
>
> I wonder, is there a way we could end up in a situation where we can't
> retransmit anymore?
> For example, sk_wmem_queued has grown so much that the new test fails.
> Then, if we legitimately need to fragment in __tcp_retransmit_skb() we
> won't be able to do so. So we will never retransmit. And if no ACK
> comes back in to make some room we are stuck, no?
We seem to be having exactly this problem. We’re running on the 4.14 branch. After recently updating our kernel, we’ve been having a problem with TCP connections stalling / dying off without disconnecting. They're stuck and never recover.
I bisected the problem to 4.14.127 commit 9daf226ff92679d09aeca1b5c1240e3607153336 (commit f070ef2ac66716357066b683fb0baf55f8191a2e upstream): tcp: tcp_fragment() should apply sane memory limits. That lead me to this thread.
Our environment is a supercomputing center: lots of servers interconnected with a non-blocking 10Gbit ethernet network. We’ve zeroed in on the problem in two situations: remote users on VPN accessing large files via samba and compute jobs using Intel MPI over TCP/IP/ethernet. It certainly affects other situations, many of our workloads have been unstable since this patch went into production, but those are the two we clearly identified as they fail reliably every time. We had to take the system down for unscheduled maintenance to roll back to an older kernel.
The TCPWqueueTooBig count is incrementing when the problem occurs.
Using ftrace/trace-cmd on an affected process, it appears the call stack is:
run_timer_softirq
expire_timers
call_timer_fn
tcp_write_timer
tcp_write_timer_handler
tcp_retransmit_timer
tcp_retransmit_skb
__tcp_retransmit_skb
tcp_fragment
Andrew Prout
MIT Lincoln Laboratory Supercomputing Center
next prev parent reply other threads:[~2019-07-10 18:36 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-17 17:03 [PATCH net 0/4] tcp: make sack processing more robust Eric Dumazet
2019-06-17 17:03 ` [PATCH net 1/4] tcp: limit payload size of sacked skbs Eric Dumazet
2019-06-17 17:14 ` Jonathan Lemon
2019-06-17 17:03 ` [PATCH net 2/4] tcp: tcp_fragment() should apply sane memory limits Eric Dumazet
2019-06-17 17:14 ` Jonathan Lemon
2019-06-18 0:18 ` Christoph Paasch
2019-06-18 2:28 ` Eric Dumazet
2019-06-18 3:19 ` Christoph Paasch
2019-06-18 3:44 ` Eric Dumazet
2019-06-18 3:53 ` Christoph Paasch
2019-06-18 4:08 ` Eric Dumazet
2019-07-10 18:23 ` Prout, Andrew - LLSC - MITLL [this message]
2019-07-10 18:28 ` Eric Dumazet
2019-07-10 18:53 ` Prout, Andrew - LLSC - MITLL
2019-07-10 19:26 ` Eric Dumazet
2019-07-11 7:28 ` Christoph Paasch
2019-07-11 9:19 ` Eric Dumazet
2019-07-11 18:26 ` Michal Kubecek
2019-07-11 18:50 ` Eric Dumazet
2019-07-11 10:18 ` Eric Dumazet
2019-07-11 17:14 ` Prout, Andrew - LLSC - MITLL
2019-07-11 18:28 ` Eric Dumazet
2019-07-11 19:04 ` Jonathan Lemon
2019-07-12 7:05 ` Eric Dumazet
2019-07-16 15:13 ` Prout, Andrew - LLSC - MITLL
2019-06-17 17:03 ` [PATCH net 3/4] tcp: add tcp_min_snd_mss sysctl Eric Dumazet
2019-06-17 17:15 ` Jonathan Lemon
2019-06-17 17:18 ` Tyler Hicks
2019-06-17 17:03 ` [PATCH net 4/4] tcp: enforce tcp_min_snd_mss in tcp_mtu_probing() Eric Dumazet
2019-06-17 17:16 ` Jonathan Lemon
2019-06-17 17:18 ` Tyler Hicks
2019-06-17 17:41 ` [PATCH net 0/4] tcp: make sack processing more robust David Miller
2019-08-02 19:02 [PATCH net 2/4] tcp: tcp_fragment() should apply sane memory limits Bernd
2019-08-02 19:14 ` Neal Cardwell
2019-08-02 19:58 ` Bernd
2019-08-14 14:41 ` Marcelo Ricardo Leitner
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=63cd99ed3d0c440185ebec3ad12327fc@ll.mit.edu \
--to=aprout@ll.mit.edu \
--cc=brucec@netflix.com \
--cc=christoph.paasch@gmail.com \
--cc=davem@davemloft.net \
--cc=dmarquess@apple.com \
--cc=eric.dumazet@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=jonathan.lemon@gmail.com \
--cc=jtl@netflix.com \
--cc=ncardwell@google.com \
--cc=netdev@vger.kernel.org \
--cc=tyhicks@canonical.com \
--cc=ycheng@google.com \
/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).