From: Eric Dumazet <eric.dumazet@gmail.com>
To: Rama Nichanamatlu <rama.nichanamatlu@oracle.com>,
Matthew Wilcox <willy@infradead.org>
Cc: Dongli Zhang <dongli.zhang@oracle.com>,
linux-mm@kvack.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
davem@davemloft.net, kuba@kernel.org,
aruna.ramakrishna@oracle.com, bert.barbe@oracle.com,
venkat.x.venkatsubra@oracle.com, manjunath.b.patil@oracle.com,
joe.jin@oracle.com, srinivas.eeda@oracle.com
Subject: Re: [PATCH 1/1] mm: avoid re-using pfmemalloc page in page_frag_alloc()
Date: Wed, 4 Nov 2020 09:50:30 +0100 [thread overview]
Message-ID: <2bce996a-0a62-9d14-4310-a4c5cb1ddeae@gmail.com> (raw)
In-Reply-To: <20201104011640.GE2445@rnichana-ThinkPad-T480>
On 11/4/20 2:16 AM, Rama Nichanamatlu wrote:
>> Thanks for providing the numbers. Do you think that dropping (up to)
>> 7 packets is acceptable?
>
> net.ipv4.tcp_syn_retries = 6
>
> tcp clients wouldn't even get that far leading to connect establish issues.
This does not really matter. If host was under memory pressure,
dropping a few packets is really not an issue.
Please do not add expensive checks in fast path, just to "not drop a packet"
even if the world is collapsing.
Also consider that NIC typically have thousands of pre-allocated page/frags
for their RX ring buffers, they might all have pfmemalloc set, so we are speaking
of thousands of packet drops before the RX-ring can be refilled with normal (non pfmemalloc) page/frags.
If we want to solve this issue more generically, we would have to try
to copy data into a non pfmemalloc frag instead of dropping skb that
had frags allocated minutes ago under memory pressure.
This copy could happen in core networking stack, but this seems adding
more pressure to mm layer under pressure.
next prev parent reply other threads:[~2020-11-04 8:50 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-03 19:32 [PATCH 1/1] mm: avoid re-using pfmemalloc page in page_frag_alloc() Dongli Zhang
2020-11-03 20:35 ` Matthew Wilcox
2020-11-03 20:57 ` Dongli Zhang
2020-11-03 21:15 ` Matthew Wilcox
2020-11-03 21:37 ` Dongli Zhang
2020-11-04 1:16 ` Rama Nichanamatlu
2020-11-04 8:50 ` Eric Dumazet [this message]
2020-11-04 12:36 ` Matthew Wilcox
2020-11-04 12:51 ` Eric Dumazet
2020-11-04 16:41 ` Dongli Zhang
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=2bce996a-0a62-9d14-4310-a4c5cb1ddeae@gmail.com \
--to=eric.dumazet@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=aruna.ramakrishna@oracle.com \
--cc=bert.barbe@oracle.com \
--cc=davem@davemloft.net \
--cc=dongli.zhang@oracle.com \
--cc=joe.jin@oracle.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=manjunath.b.patil@oracle.com \
--cc=netdev@vger.kernel.org \
--cc=rama.nichanamatlu@oracle.com \
--cc=srinivas.eeda@oracle.com \
--cc=venkat.x.venkatsubra@oracle.com \
--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).