netdev - [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-next>] [day] [month] [year] [list]

Message-ID: <4910D47E.4030004@cosmosbay.com>
Date:	Wed, 05 Nov 2008 00:02:22 +0100
From:	Eric Dumazet <dada1@...mosbay.com>
To:	Linux Netdev List <netdev@...r.kernel.org>,
	Corey Minyard <minyard@....org>
Subject: [RFC] skb_free_datagram() doing something expensive ?

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

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html