From: Andrew Morton <akpm@linux-foundation.org>
To: Dave Chinner <david@fromorbit.com>
Cc: Michal Hocko <mhocko@suse.cz>, Glauber Costa <glommer@gmail.com>,
linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: linux-next: slab shrinkers: BUG at mm/list_lru.c:92
Date: Wed, 10 Jul 2013 20:03:37 -0700 [thread overview]
Message-ID: <20130710200337.cd9a05d6.akpm@linux-foundation.org> (raw)
In-Reply-To: <20130711022634.GZ3438@dastard>
On Thu, 11 Jul 2013 12:26:34 +1000 Dave Chinner <david@fromorbit.com> wrote:
> > Just for reference. wait_on_page_writeback is issued only for memcg
> > reclaim because there is no other throttling mechanism to prevent from
> > too many dirty pages on the list, thus pre-mature OOM killer. See
> > e62e384e9d (memcg: prevent OOM with too many dirty pages) for more
> > details. The original patch relied on may_enter_fs but that check
> > disappeared by later changes by c3b94f44fc (memcg: further prevent OOM
> > with too many dirty pages).
>
> Aye. That's the exact code I was looking at yesterday and wondering
> "how the hell is waiting on page writeback valid in GFP_NOFS
> context?". It seems that memcg reclaim is intentionally ignoring
> GFP_NOFS to avoid OOM issues. That's a memcg implementation problem,
> not a filesystem or LRU infrastructure problem....
Yup, c3b94f44fc shouldn't have done that.
Throttling by waiting on a specific page is indeed prone to deadlocks
and has a number of efficiency problems as well: if 1,000,000 pages
came clean while you're waiting for *this* page to come clean, you're
left looking pretty stupid.
Hence congestion_wait(), which perhaps can save us here. I'm not sure
how the wait_on_page_writeback() got back in there - I must have been
asleep at the time.
--
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: Andrew Morton <akpm@linux-foundation.org>
To: Dave Chinner <david@fromorbit.com>
Cc: Michal Hocko <mhocko@suse.cz>, Glauber Costa <glommer@gmail.com>,
linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: linux-next: slab shrinkers: BUG at mm/list_lru.c:92
Date: Wed, 10 Jul 2013 20:03:37 -0700 [thread overview]
Message-ID: <20130710200337.cd9a05d6.akpm@linux-foundation.org> (raw)
In-Reply-To: <20130711022634.GZ3438@dastard>
On Thu, 11 Jul 2013 12:26:34 +1000 Dave Chinner <david@fromorbit.com> wrote:
> > Just for reference. wait_on_page_writeback is issued only for memcg
> > reclaim because there is no other throttling mechanism to prevent from
> > too many dirty pages on the list, thus pre-mature OOM killer. See
> > e62e384e9d (memcg: prevent OOM with too many dirty pages) for more
> > details. The original patch relied on may_enter_fs but that check
> > disappeared by later changes by c3b94f44fc (memcg: further prevent OOM
> > with too many dirty pages).
>
> Aye. That's the exact code I was looking at yesterday and wondering
> "how the hell is waiting on page writeback valid in GFP_NOFS
> context?". It seems that memcg reclaim is intentionally ignoring
> GFP_NOFS to avoid OOM issues. That's a memcg implementation problem,
> not a filesystem or LRU infrastructure problem....
Yup, c3b94f44fc shouldn't have done that.
Throttling by waiting on a specific page is indeed prone to deadlocks
and has a number of efficiency problems as well: if 1,000,000 pages
came clean while you're waiting for *this* page to come clean, you're
left looking pretty stupid.
Hence congestion_wait(), which perhaps can save us here. I'm not sure
how the wait_on_page_writeback() got back in there - I must have been
asleep at the time.
next prev parent reply other threads:[~2013-07-11 3:03 UTC|newest]
Thread overview: 127+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-17 14:18 linux-next: slab shrinkers: BUG at mm/list_lru.c:92 Michal Hocko
2013-06-17 14:18 ` Michal Hocko
2013-06-17 15:14 ` Glauber Costa
2013-06-17 15:14 ` Glauber Costa
2013-06-17 15:33 ` Michal Hocko
2013-06-17 15:33 ` Michal Hocko
2013-06-17 16:54 ` Glauber Costa
2013-06-17 16:54 ` Glauber Costa
2013-06-18 7:42 ` Michal Hocko
2013-06-18 7:42 ` Michal Hocko
2013-06-17 21:35 ` Andrew Morton
2013-06-17 21:35 ` Andrew Morton
2013-06-17 22:30 ` Glauber Costa
2013-06-18 2:46 ` Dave Chinner
2013-06-18 2:46 ` Dave Chinner
2013-06-18 6:31 ` Glauber Costa
2013-06-18 6:31 ` Glauber Costa
2013-06-18 8:24 ` Michal Hocko
2013-06-18 8:24 ` Michal Hocko
2013-06-18 10:44 ` Michal Hocko
2013-06-18 10:44 ` Michal Hocko
2013-06-18 13:50 ` Michal Hocko
2013-06-18 13:50 ` Michal Hocko
2013-06-25 2:27 ` Dave Chinner
2013-06-25 2:27 ` Dave Chinner
2013-06-26 8:15 ` Michal Hocko
2013-06-26 8:15 ` Michal Hocko
2013-06-26 23:24 ` Dave Chinner
2013-06-26 23:24 ` Dave Chinner
2013-06-27 14:54 ` Michal Hocko
2013-06-27 14:54 ` Michal Hocko
2013-06-28 8:39 ` Michal Hocko
2013-06-28 8:39 ` Michal Hocko
2013-06-28 14:31 ` Glauber Costa
2013-06-28 14:31 ` Glauber Costa
2013-06-28 15:12 ` Michal Hocko
2013-06-28 15:12 ` Michal Hocko
2013-06-29 2:55 ` Dave Chinner
2013-06-29 2:55 ` Dave Chinner
2013-06-30 18:33 ` Michal Hocko
2013-07-01 1:25 ` Dave Chinner
2013-07-01 1:25 ` Dave Chinner
2013-07-01 7:50 ` Michal Hocko
2013-07-01 7:50 ` Michal Hocko
2013-07-01 8:10 ` Dave Chinner
2013-07-01 8:10 ` Dave Chinner
2013-07-02 9:22 ` Michal Hocko
2013-07-02 12:19 ` Dave Chinner
2013-07-02 12:19 ` Dave Chinner
2013-07-02 12:44 ` Michal Hocko
2013-07-02 12:44 ` Michal Hocko
2013-07-03 11:24 ` Dave Chinner
2013-07-03 11:24 ` Dave Chinner
2013-07-03 14:08 ` Glauber Costa
2013-07-03 14:08 ` Glauber Costa
2013-07-04 16:36 ` Michal Hocko
2013-07-04 16:36 ` Michal Hocko
2013-07-08 12:53 ` Michal Hocko
2013-07-08 21:04 ` Andrew Morton
2013-07-08 21:04 ` Andrew Morton
2013-07-09 17:34 ` Glauber Costa
2013-07-09 17:34 ` Glauber Costa
2013-07-09 17:51 ` Andrew Morton
2013-07-09 17:51 ` Andrew Morton
2013-07-09 17:32 ` Glauber Costa
2013-07-09 17:32 ` Glauber Costa
2013-07-09 17:50 ` Andrew Morton
2013-07-09 17:50 ` Andrew Morton
2013-07-09 17:57 ` Glauber Costa
2013-07-09 17:57 ` Glauber Costa
2013-07-09 17:57 ` Michal Hocko
2013-07-09 17:57 ` Michal Hocko
2013-07-09 21:39 ` Andrew Morton
2013-07-09 21:39 ` Andrew Morton
2013-07-10 2:31 ` Dave Chinner
2013-07-10 2:31 ` Dave Chinner
2013-07-10 7:34 ` Michal Hocko
2013-07-10 7:34 ` Michal Hocko
2013-07-10 8:06 ` Michal Hocko
2013-07-10 8:06 ` Michal Hocko
2013-07-11 2:26 ` Dave Chinner
2013-07-11 2:26 ` Dave Chinner
2013-07-11 3:03 ` Andrew Morton [this message]
2013-07-11 3:03 ` Andrew Morton
2013-07-11 13:23 ` Michal Hocko
2013-07-11 13:23 ` Michal Hocko
2013-07-12 1:42 ` Hugh Dickins
2013-07-12 1:42 ` Hugh Dickins
2013-07-13 3:29 ` Dave Chinner
2013-07-13 3:29 ` Dave Chinner
2013-07-15 9:14 ` Michal Hocko
2013-07-15 9:14 ` Michal Hocko
2013-06-18 6:26 ` Glauber Costa
2013-06-18 8:25 ` Michal Hocko
2013-06-18 8:25 ` Michal Hocko
2013-06-19 7:13 ` Michal Hocko
2013-06-19 7:13 ` Michal Hocko
2013-06-19 7:35 ` Glauber Costa
2013-06-19 7:35 ` Glauber Costa
2013-06-19 8:52 ` Glauber Costa
2013-06-19 8:52 ` Glauber Costa
2013-06-19 13:57 ` Michal Hocko
2013-06-19 13:57 ` Michal Hocko
2013-06-19 14:02 ` Glauber Costa
2013-06-19 14:02 ` Glauber Costa
2013-06-19 14:28 ` Michal Hocko
2013-06-19 14:28 ` Michal Hocko
2013-06-20 14:11 ` Glauber Costa
2013-06-20 14:11 ` Glauber Costa
2013-06-20 15:12 ` Michal Hocko
2013-06-20 15:16 ` Michal Hocko
2013-06-20 15:16 ` Michal Hocko
2013-06-21 9:00 ` Michal Hocko
2013-06-21 9:00 ` Michal Hocko
2013-06-23 11:51 ` Glauber Costa
2013-06-23 11:51 ` Glauber Costa
2013-06-23 11:55 ` Glauber Costa
2013-06-25 2:29 ` Dave Chinner
2013-06-25 2:29 ` Dave Chinner
2013-06-26 8:22 ` Michal Hocko
2013-06-26 8:22 ` Michal Hocko
2013-06-18 8:19 ` Michal Hocko
2013-06-18 8:19 ` Michal Hocko
2013-06-18 8:21 ` Glauber Costa
2013-06-18 8:21 ` Glauber Costa
2013-06-18 8:26 ` Michal Hocko
2013-06-18 8:26 ` Michal Hocko
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=20130710200337.cd9a05d6.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=david@fromorbit.com \
--cc=glommer@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.cz \
/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.