From: Joonsoo Kim <iamjoonsoo.kim@lge.com>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: linux-mm@kvack.org
Subject: Re: isolate_freepages_block and excessive CPU usage by OSD process
Date: Thu, 11 Dec 2014 12:08:01 +0900 [thread overview]
Message-ID: <20141211030801.GA16381@js1304-P5Q-DELUXE> (raw)
In-Reply-To: <5488616B.3070104@suse.cz>
On Wed, Dec 10, 2014 at 04:06:19PM +0100, Vlastimil Babka wrote:
> On 12/05/2014 02:07 AM, Joonsoo Kim wrote:
> >------------>8-----------------
> > From b7daa232c327a4ebbb48ca0538a2dbf9ca83ca1f Mon Sep 17 00:00:00 2001
> >From: Joonsoo Kim <iamjoonsoo.kim@lge.com>
> >Date: Fri, 5 Dec 2014 09:38:30 +0900
> >Subject: [PATCH] mm/compaction: stop the compaction if there isn't enough
> > freepage
> >
> >After compaction_suitable() passed, there is no check whether the system
> >has enough memory to compact and blindly try to find freepage through
> >iterating all memory range. This causes excessive cpu usage in low free
> >memory condition and finally compaction would be failed. It makes sense
> >that compaction would be stopped if there isn't enough freepage. So,
> >this patch adds watermark check to isolate_freepages() in order to stop
> >the compaction in this case.
> >
> >Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
> >---
> > mm/compaction.c | 9 +++++++++
> > 1 file changed, 9 insertions(+)
> >
> >diff --git a/mm/compaction.c b/mm/compaction.c
> >index e005620..31c4009 100644
> >--- a/mm/compaction.c
> >+++ b/mm/compaction.c
> >@@ -828,6 +828,7 @@ static void isolate_freepages(struct compact_control *cc)
> > unsigned long low_pfn; /* lowest pfn scanner is able to scan */
> > int nr_freepages = cc->nr_freepages;
> > struct list_head *freelist = &cc->freepages;
> >+ unsigned long watermark = low_wmark_pages(zone) + (2UL << cc->order);
>
> Given that we maybe have already isolated up to 31 free pages (if
> cc->nr_migratepages is the maximum 32), then this is somewhat
> stricter than the check in isolation_suitable() (when nothing was
> isolated yet) and may interrupt us prematurely. We should allow for
> some slack.
Okay. Will allow some slack.
>
> >
> > /*
> > * Initialise the free scanner. The starting point is where we last
> >@@ -903,6 +904,14 @@ static void isolate_freepages(struct compact_control *cc)
> > */
> > if (cc->contended)
> > break;
> >+
> >+ /*
> >+ * Watermarks for order-0 must be met for compaction.
> >+ * See compaction_suitable for more detailed explanation.
> >+ */
> >+ if (!zone_watermark_ok(zone, 0, watermark,
> >+ cc->classzone_idx, cc->alloc_flags))
> >+ break;
> > }
>
> I'm a also bit concerned about the overhead of doing this in each pageblock.
Yep, we can do it whenever SWAP_CLUSTER_MAX pageblock is scanned. It
will reduce overhead somewhat. I will change it.
>
> I wonder if there could be a mechanism where a process entering
> reclaim or compaction with the goal of meeting the watermarks to
> allocate, should increase the watermarks needed for further parallel
> allocation attempts to pass. Then it shouldn't happen that somebody
> else steals the memory.
I don't know, neither.
Thanks.
>
> > /* split_free_page does not map the pages */
> >
>
> --
> 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>
--
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>
next prev parent reply other threads:[~2014-12-11 3:04 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CABYiri-do2YdfBx=r+u1kwXkEwN4v+yeRSHB-ODXo4gMFgW-Fg.mail.gmail.com>
2014-11-19 1:21 ` Christian Marie
2014-11-19 18:03 ` Andrey Korolyov
2014-11-19 21:20 ` Christian Marie
2014-11-19 23:10 ` Vlastimil Babka
2014-11-19 23:49 ` Andrey Korolyov
2014-11-20 3:30 ` Christian Marie
2014-11-21 2:35 ` Christian Marie
2014-11-23 9:33 ` Christian Marie
2014-11-24 21:48 ` Andrey Korolyov
2014-11-28 8:03 ` Joonsoo Kim
2014-11-28 9:26 ` Vlastimil Babka
2014-12-01 8:31 ` Joonsoo Kim
2014-12-02 1:47 ` Christian Marie
2014-12-02 4:53 ` Joonsoo Kim
2014-12-02 5:06 ` Christian Marie
2014-12-03 4:04 ` Christian Marie
2014-12-03 8:05 ` Joonsoo Kim
2014-12-04 23:30 ` Vlastimil Babka
2014-12-05 5:50 ` Christian Marie
2014-12-03 7:57 ` Joonsoo Kim
2014-12-04 7:30 ` Christian Marie
2014-12-04 7:51 ` Christian Marie
2014-12-05 1:07 ` Joonsoo Kim
2014-12-05 5:55 ` Christian Marie
2014-12-08 7:19 ` Joonsoo Kim
2014-12-10 15:06 ` Vlastimil Babka
2014-12-11 3:08 ` Joonsoo Kim [this message]
2014-12-02 15:46 ` Vlastimil Babka
2014-12-03 7:49 ` Joonsoo Kim
2014-12-03 12:43 ` Vlastimil Babka
2014-12-04 6:53 ` Joonsoo Kim
2014-11-15 11:48 Andrey Korolyov
2014-11-15 16:32 ` Vlastimil Babka
2014-11-15 17:10 ` Andrey Korolyov
2014-11-15 18:45 ` Vlastimil Babka
2014-11-15 18:52 ` Andrey Korolyov
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=20141211030801.GA16381@js1304-P5Q-DELUXE \
--to=iamjoonsoo.kim@lge.com \
--cc=linux-mm@kvack.org \
--cc=vbabka@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox