netdev - Re: [RFC] skb_free_datagram() doing something expensive ?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <49112984.3000808@cosmosbay.com>
Date:	Wed, 05 Nov 2008 06:05:08 +0100
From:	Eric Dumazet <dada1@...mosbay.com>
To:	"David S. Miller" <davem@...emloft.net>
CC:	Linux Netdev List <netdev@...r.kernel.org>,
	Corey Minyard <minyard@....org>
Subject: Re: [RFC] skb_free_datagram() doing something expensive ?

Eric Dumazet a écrit :
> Hi all
> 
> I noticed high contention on udp_memory_allocated on a typical VOIP 
> application.
> 
> (Now that oprofile correctly runs on my machine :) )
> 
> I can see that skb_free_datagram() is :
> 
> void skb_free_datagram(struct sock *sk, struct sk_buff *skb)
> {
>        kfree_skb(skb);
>        sk_mem_reclaim(sk);
> }
> 
> So each time an UDP packet is received, we must touch udp_memory_allocated
> 
> Each time application reads a packet, we call sk_mem_reclaim() and touch 
> again udp_memory_allocated.
> 
> Surely this cannot be correct ?
> 
> If this is correct, time is to resurrect a patch to make 
> proto->memory_allocated a percpu_counter
> or something to have a percpu reserve of say 64 or 128 pages to avoid 
> cache line trashing...
> 
> tcp_memory_allocated do not have this problem, since tcp carefully calls 
> sk_mem_reclaim(sk) only on
> selected paths, not on fast path.
> 
> Thanks
> 
> 

What we can do is to avoid reclaiming space if forward_alloc is less than a page

We did that in the past, when introducing sk_mem_reclaim_partial() in 
commit 9993e7d313e80bdc005d09c7def91903e0068f07
([TCP]: Do not purge sk_forward_alloc entirely in tcp_delack_timer())

This patch gives a nice speedup on UDP, particularly for multiple
RTP flows, where each flow has a medium trafic (say VOIP trafic)

[PATCH] net: sk_free_datagram() should use sk_mem_reclaim_partial()

I noticed a contention on udp_memory_allocated on regular UDP applications.

While tcp_memory_allocated is seldom used, it appears each incoming UDP frame
is currently touching udp_memory_allocated when queued, and when received by
application.

One possible solution is to use sk_mem_reclaim_partial() instead of
sk_mem_reclaim(), so that we keep a small reserve (less than one page)
of memory for each UDP socket.

We did something very similar on TCP side in commit
9993e7d313e80bdc005d09c7def91903e0068f07
([TCP]: Do not purge sk_forward_alloc entirely in tcp_delack_timer())

A more complex solution would need to convert prot->memory_allocated to
use a percpu_counter with batches of 64 or 128 pages.

Signed-off-by: Eric Dumazet <dada1@...mosbay.com>

View attachment "udp_mem_reclaim.patch" of type "text/plain" (612 bytes)