On Fri, Jan 17, 2020 at 12:51 PM Eric Dumazet [off-list ref] wrote:

On 1/17/20 9:27 AM, Paolo Abeni wrote:

quoted

Williem reported that after commit 0d4a6608f68c ("udp: do rmem bulk
free even if the rx sk queue is empty") the memory allocated by
an almost idle system with many UDP sockets can grow a lot.

This change addresses the issue enabling memory pressure tracking
for UDP and flushing the fwd allocated memory on dequeue if the
UDP protocol is under memory pressure.

Note that with this patch applied, the system allocates more
liberally memory for UDP sockets while the total memory usage is
below udp_mem[1], while the vanilla kernel would allow at most a
single page per socket when UDP memory usage goes above udp_mem[0]
- see __sk_mem_raise_allocated().

Reported-and-diagnosed-by: Willem de Bruijn [off-list ref]
Fixes: commit 0d4a6608f68c ("udp: do rmem bulk free even if the rx sk queue is empty")

Thanks a lot for the quick follow-up, Paolo!

Not a proper Fixes: tag

And to give credit where it's due: Eric diagnosed the issue.

Frankly I would rather revert this patch, unless you show how much things were improved.

In response to your question in the cover letter, I also think that
for net the three-line revert patch is more obviously correct.

Memory pressure might be helpful in net-next with some iteration, of course.

Where in the UDP code the forward allocations will be released while udp_memory_pressure
is hit ?

TCP has many calls to sk_mem_reclaim() and sk_mem_reclaim_partial() to try
to gracefully exit memory pressure.