[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1357698749.27446.6.camel@edumazet-glaptop>
Date: Tue, 08 Jan 2013 18:32:29 -0800
From: Eric Dumazet <eric.dumazet@...il.com>
To: Eric Wong <normalperson@...t.net>
Cc: Mel Gorman <mgorman@...e.de>, linux-mm@...ck.org,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
Rik van Riel <riel@...hat.com>,
Minchan Kim <minchan@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: ppoll() stuck on POLLIN while TCP peer is sending
On Tue, 2013-01-08 at 18:14 -0800, Eric Dumazet wrote:
> On Tue, 2013-01-08 at 23:23 +0000, Eric Wong wrote:
> > Mel Gorman <mgorman@...e.de> wrote:
> > > Please try the following patch. However, even if it works the benefit of
> > > capture may be so marginal that partially reverting it and simplifying
> > > compaction.c is the better decision.
> >
> > I already got my VM stuck on this one. I had two twosleepy instances,
> > 2774 was the one that got stuck (also confirmed by watching top).
> >
> > Btw, have you been able to reproduce this on your end?
> >
> > I think the easiest reproduction on my 2-core VM is by running 2
> > twosleepy processes and doing the following to dirty a lot of pages:
>
> Given the persistent sk_stream_wait_memory() traces I suspect a plain
> TCP bug, triggered by some extra wait somewhere.
>
> Please mm guys don't spend too much time right now, I'll try to
> reproduce the problem.
>
> Don't be confused by sk_stream_wait_memory() name.
> A thread is stuck here because TCP stack is failing to wake it.
>
Hmm, it seems sk_filter() can return -ENOMEM because skb has the
pfmemalloc() set.
It seems nobody really tested this stuff under memory stress.
Mel, it looks like you are the guy who could fix this, after all ;)
One TCP socket keeps retransmitting an SKB via loopback, and TCP stack
drops the packet again and again.
commit c93bdd0e03e848555d144eb44a1f275b871a8dd5
Author: Mel Gorman <mgorman@...e.de>
Date: Tue Jul 31 16:44:19 2012 -0700
netvm: allow skb allocation to use PFMEMALLOC reserves
Change the skb allocation API to indicate RX usage and use this to fall
back to the PFMEMALLOC reserve when needed. SKBs allocated from the
reserve are tagged in skb->pfmemalloc. If an SKB is allocated from the
reserve and the socket is later found to be unrelated to page reclaim, the
packet is dropped so that the memory remains available for page reclaim.
Network protocols are expected to recover from this packet loss.
[a.p.zijlstra@...llo.nl: Ideas taken from various patches]
[davem@...emloft.net: Use static branches, coding style corrections]
[sebastian@...akpoint.cc: Avoid unnecessary cast, fix !CONFIG_NET build]
Signed-off-by: Mel Gorman <mgorman@...e.de>
Acked-by: David S. Miller <davem@...emloft.net>
Cc: Neil Brown <neilb@...e.de>
Cc: Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc: Mike Christie <michaelc@...wisc.edu>
Cc: Eric B Munson <emunson@...bm.net>
Cc: Eric Dumazet <eric.dumazet@...il.com>
Cc: Sebastian Andrzej Siewior <sebastian@...akpoint.cc>
Cc: Mel Gorman <mgorman@...e.de>
Cc: Christoph Lameter <cl@...ux.com>
Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@...ux-foundation.org>
--
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
Powered by blists - more mailing lists