All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mel Gorman <mgorman@suse.de>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Eric Wong <normalperson@yhbt.net>,
	linux-mm@kvack.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, Rik van Riel <riel@redhat.com>,
	Minchan Kim <minchan@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: ppoll() stuck on POLLIN while TCP peer is sending
Date: Wed, 9 Jan 2013 13:42:48 +0000	[thread overview]
Message-ID: <20130109134248.GE13304@suse.de> (raw)
In-Reply-To: <1357698749.27446.6.camel@edumazet-glaptop>

On Tue, Jan 08, 2013 at 06:32:29PM -0800, Eric Dumazet wrote:
> 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@suse.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.
> 

The skb should not have pfmemalloc set in most cases, particularly after
cfd19c5a (mm: only set page->pfmemalloc when ALLOC_NO_WATERMARKS was used)
but the capture patch also failed to clear pfmemalloc properly so it could
be set in error.

-- 
Mel Gorman
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Mel Gorman <mgorman@suse.de>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Eric Wong <normalperson@yhbt.net>,
	linux-mm@kvack.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, Rik van Riel <riel@redhat.com>,
	Minchan Kim <minchan@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: ppoll() stuck on POLLIN while TCP peer is sending
Date: Wed, 9 Jan 2013 13:42:48 +0000	[thread overview]
Message-ID: <20130109134248.GE13304@suse.de> (raw)
In-Reply-To: <1357698749.27446.6.camel@edumazet-glaptop>

On Tue, Jan 08, 2013 at 06:32:29PM -0800, Eric Dumazet wrote:
> 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@suse.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.
> 

The skb should not have pfmemalloc set in most cases, particularly after
cfd19c5a (mm: only set page->pfmemalloc when ALLOC_NO_WATERMARKS was used)
but the capture patch also failed to clear pfmemalloc properly so it could
be set in error.

-- 
Mel Gorman
SUSE Labs

  parent reply	other threads:[~2013-01-09 13:42 UTC|newest]

Thread overview: 88+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-28  1:45 ppoll() stuck on POLLIN while TCP peer is sending Eric Wong
2012-12-28  7:06 ` Eric Wong
2012-12-29 11:34   ` Eric Wong
2012-12-31 13:21 ` [PATCH] poll: prevent missed events if _qproc is NULL Eric Wong
2012-12-31 23:24   ` Eric Wong
2013-01-01 16:58     ` Junchang(Jason) Wang
2013-01-01 18:42   ` Eric Dumazet
2013-01-01 21:00     ` Eric Wong
2013-01-01 21:17       ` Eric Wong
2013-01-01 22:53         ` Linus Torvalds
2013-01-01 23:21           ` Junchang(Jason) Wang
2013-01-01 23:56           ` [PATCH] epoll: prevent missed events on EPOLL_CTL_MOD Eric Wong
2013-01-02 17:45             ` Eric Dumazet
2013-01-02 18:40               ` Eric Wong
2013-01-02 19:03                 ` Eric Dumazet
2013-01-02 19:32                   ` Eric Wong
2013-01-02 22:08                     ` Eric Dumazet
2013-01-02 21:16             ` Eric Wong
2013-01-02 20:08 ` ppoll() stuck on POLLIN while TCP peer is sending Eric Wong
2013-01-02 20:08   ` Eric Wong
2013-01-02 20:47   ` Eric Wong
2013-01-02 20:47     ` Eric Wong
2013-01-03 13:41     ` Eric Dumazet
2013-01-03 13:41       ` Eric Dumazet
2013-01-03 18:32       ` Eric Wong
2013-01-03 18:32         ` Eric Wong
2013-01-03 23:45         ` Eric Wong
2013-01-03 23:45           ` Eric Wong
2013-01-04  0:26           ` Eric Wong
2013-01-04  0:26             ` Eric Wong
2013-01-04  3:52             ` Eric Wong
2013-01-04  3:52               ` Eric Wong
2013-01-04 16:01   ` Mel Gorman
2013-01-04 16:01     ` Mel Gorman
2013-01-04 17:15     ` Eric Dumazet
2013-01-04 17:15       ` Eric Dumazet
2013-01-04 17:59     ` Eric Wong
2013-01-04 17:59       ` Eric Wong
2013-01-05  1:07     ` Eric Wong
2013-01-05  1:07       ` Eric Wong
2013-01-06 12:07     ` Eric Wong
2013-01-06 12:07       ` Eric Wong
2013-01-07 12:25       ` Mel Gorman
2013-01-07 12:25         ` Mel Gorman
2013-01-07 22:38         ` Eric Dumazet
2013-01-07 22:38           ` Eric Dumazet
2013-01-08  0:21           ` Eric Wong
2013-01-08  0:21             ` Eric Wong
2013-01-07 22:38         ` Eric Wong
2013-01-07 22:38           ` Eric Wong
2013-01-08 20:14           ` Eric Wong
2013-01-08 20:14             ` Eric Wong
2013-01-08 22:43           ` Mel Gorman
2013-01-08 22:43             ` Mel Gorman
2013-01-08 23:23             ` Eric Wong
2013-01-08 23:23               ` Eric Wong
2013-01-09  2:14               ` Eric Dumazet
2013-01-09  2:14                 ` Eric Dumazet
2013-01-09  2:32                 ` Eric Dumazet
2013-01-09  2:32                   ` Eric Dumazet
2013-01-09  2:54                   ` Eric Dumazet
2013-01-09  2:54                     ` Eric Dumazet
2013-01-09  3:55                     ` Eric Wong
2013-01-09  3:55                       ` Eric Wong
2013-01-09  8:42                       ` Eric Wong
2013-01-09  8:42                         ` Eric Wong
2013-01-09  8:51                         ` Eric Wong
2013-01-09  8:51                           ` Eric Wong
2013-01-09 13:42                   ` Mel Gorman [this message]
2013-01-09 13:42                     ` Mel Gorman
2013-01-09 13:37               ` Mel Gorman
2013-01-09 13:37                 ` Mel Gorman
2013-01-09 13:50                 ` Mel Gorman
2013-01-09 13:50                   ` Mel Gorman
2013-01-10  9:25                 ` Eric Wong
2013-01-10  9:25                   ` Eric Wong
2013-01-10 19:42                   ` Mel Gorman
2013-01-10 19:42                     ` Mel Gorman
2013-01-10 20:03                     ` Eric Wong
2013-01-10 20:03                       ` Eric Wong
2013-01-10 20:58                     ` Eric Dumazet
2013-01-10 20:58                       ` Eric Dumazet
2013-01-11  0:51                     ` Eric Wong
2013-01-11  0:51                       ` Eric Wong
2013-01-11  9:30                       ` Mel Gorman
2013-01-11  9:30                         ` Mel Gorman
2013-01-09 21:29             ` Eric Wong
2013-01-09 21:29               ` Eric Wong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130109134248.GE13304@suse.de \
    --to=mgorman@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=eric.dumazet@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=minchan@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=normalperson@yhbt.net \
    --cc=riel@redhat.com \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.