diff options
| author | Eric Dumazet <[email protected]> | 2008-11-05 09:38:06 +0000 |
|---|---|---|
| committer | David S. Miller <[email protected]> | 2008-11-05 09:38:06 +0000 |
| commit | 270acefafeb74ce2fe93d35b75733870bf1e11e7 (patch) | |
| tree | 9368122a53b2834d2cd7894a1a316a9fde5d19ca /drivers/net/loopback.c | |
| parent | dccp: Cleanup routines for feature negotiation (diff) | |
| download | kernel-270acefafeb74ce2fe93d35b75733870bf1e11e7.tar.gz kernel-270acefafeb74ce2fe93d35b75733870bf1e11e7.zip | |
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 <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Diffstat (limited to 'drivers/net/loopback.c')
0 files changed, 0 insertions, 0 deletions