From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Mon, 31 Dec 2007 15:42:42 +0100
> Maybe we need to introduce some mechanism to let sk_forward between 0 and
> SK_MEM_QUANTUM (inclusive).
>
> static inline void sk_mem_reclaim_overpage(struct sock *sk)
> {
> if (sk->sk_forward_alloc > SK_MEM_QUANTUM) {
> __sk_mem_reclaim(sk);
> }
> }
>
> and use sk_mem_reclaim_overpage() instead of sk_mem_reclaim() in
> tcp_delack_timer() ?
This makes a lot of sense to me, it is definitely doing the wrong
thing here for the load you describe.
I've applied the following to net-2.6.25 and I am definitely
willing to put this into 2.6.24 and -stable if you think that's
worthwhile too.
[TCP]: Do not purge sk_forward_alloc entirely in tcp_delack_timer().
Otherwise we beat heavily on the global tcp_memory atomics
when all of the sockets in the system are slowly sending
perioding packet clumps.
Noticed and suggested by Eric Dumazet.
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
---
include/net/sock.h | 8 ++++++++
net/ipv4/tcp_timer.c | 2 +-
2 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/include/net/sock.h b/include/net/sock.h
index 89e04e4..d24b826 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -759,6 +759,14 @@ static inline void sk_mem_reclaim(struct sock *sk)
__sk_mem_reclaim(sk);
}
+static inline void sk_mem_reclaim_partial(struct sock *sk)
+{
+ if (!sk_has_account(sk))
+ return;
+ if (sk->sk_forward_alloc > SK_MEM_QUANTUM)
+ __sk_mem_reclaim(sk);
+}
+
static inline void sk_mem_charge(struct sock *sk, int size)
{
if (!sk_has_account(sk))
diff --git a/net/ipv4/tcp_timer.c b/net/ipv4/tcp_timer.c
index 17931be..803d758 100644
--- a/net/ipv4/tcp_timer.c
+++ b/net/ipv4/tcp_timer.c
@@ -186,7 +186,7 @@ static void tcp_delack_timer(unsigned long data)
goto out_unlock;
}
- sk_mem_reclaim(sk);
+ sk_mem_reclaim_partial(sk);
if (sk->sk_state == TCP_CLOSE || !(icsk->icsk_ack.pending &
ICSK_ACK_TIMER))
goto out;
--
1.5.4.rc2.84.gf85fd
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
