From: Vlastimil Babka <vbabka@suse.cz>
To: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: "P. Christeas" <xrg@linux.gr>,
linux-mm@kvack.org, lkml <linux-kernel@vger.kernel.org>,
David Rientjes <rientjes@google.com>,
Norbert Preining <preining@logic.at>,
Markus Trippelsdorf <markus@trippelsdorf.de>,
Pavel Machek <pavel@ucw.cz>
Subject: Re: Early test: hangs in mm/compact.c w. Linus's 12d7aacab56e9ef185c
Date: Mon, 10 Nov 2014 08:53:38 +0100 [thread overview]
Message-ID: <54606F02.5070808@suse.cz> (raw)
In-Reply-To: <20141110060726.GA4900@js1304-P5Q-DELUXE>
On 11/10/2014 07:07 AM, Joonsoo Kim wrote:
> On Sat, Nov 08, 2014 at 11:18:37PM +0100, Vlastimil Babka wrote:
>> On 11/08/2014 02:11 PM, P. Christeas wrote:
>>
>> Hi,
>>
>> I think I finally found the cause by staring into the code... CCing
>> people from all 4 separate threads I know about this issue.
>> The problem with finding the cause was that the first report I got from
>> Markus was about isolate_freepages_block() overhead, and later Norbert
>> reported that reverting a patch for isolate_freepages* helped. But the
>> problem seems to be that although the loop in isolate_migratepages exits
>> because the scanners almost meet (they are within same pageblock), they
>> don't truly meet, therefore compact_finished() decides to continue, but
>> isolate_migratepages() exits immediately... boom! But indeed e14c720efdd7
>> made this situation possible, as free scaner pfn can now point to a
>> middle of pageblock.
>
> Indeed.
>
>>
>> So I hope the attached patch will fix the soft-lockup issues in
>> compact_zone. Please apply on 3.18-rc3 or later without any other reverts,
>> and test. It probably won't help Markus and his isolate_freepages_block()
>> overhead though...
>
> Yes, I found this bug too, but, it can't explain
> isolate_freepages_block() overhead. Anyway, I can't find another bug
> related to isolate_freepages_block(). :/
Thanks for checking.
>> Thanks,
>> Vlastimil
>>
>> ------8<------
>> >From fbf8eb0bcd2897090312e23da6a31bad9cc6b337 Mon Sep 17 00:00:00 2001
>> From: Vlastimil Babka <vbabka@suse.cz>
>> Date: Sat, 8 Nov 2014 22:20:43 +0100
>> Subject: [PATCH] mm, compaction: prevent endless loop in migrate scanner
>>
>> ---
>> mm/compaction.c | 8 ++++++--
>> 1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/mm/compaction.c b/mm/compaction.c
>> index ec74cf0..1b7a1be 100644
>> --- a/mm/compaction.c
>> +++ b/mm/compaction.c
>> @@ -1029,8 +1029,12 @@ static isolate_migrate_t isolate_migratepages(struct zone *zone,
>> }
>>
>> acct_isolated(zone, cc);
>> - /* Record where migration scanner will be restarted */
>> - cc->migrate_pfn = low_pfn;
>> + /*
>> + * Record where migration scanner will be restarted. If we end up in
>> + * the same pageblock as the free scanner, make the scanners fully
>> + * meet so that compact_finished() terminates compaction.
>> + */
>> + cc->migrate_pfn = (end_pfn <= cc->free_pfn) ? low_pfn : cc->free_pfn;
>>
>> return cc->nr_migratepages ? ISOLATE_SUCCESS : ISOLATE_NONE;
>> }
>
> IMHO, proper fix is not to change this logic, but, to change decision
> logic in compact_finished() and in compact_zone(). Maybe helper
> function would be good for readability.
OK but I would think that to fix 3.18 ASAP and not introduce more
regressions, go with the patch above first, as it is the minimal fix and
people already test it. Then we can implement your suggestion later as a
cleanup for 3.19?
Vlastimil
> Thanks.
>
--
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-11-10 7:53 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-04 7:26 P. Christeas
2014-11-04 8:55 ` Vlastimil Babka
2014-11-04 9:36 ` P. Christeas
2014-11-05 15:26 ` Vlastimil Babka
2014-11-05 16:02 ` P. Christeas
2014-11-06 19:23 ` P. Christeas
2014-11-06 21:38 ` Vlastimil Babka
2014-11-08 13:11 ` P. Christeas
2014-11-08 22:18 ` Vlastimil Babka
2014-11-09 8:27 ` Pavel Machek
2014-11-09 9:43 ` Vlastimil Babka
2014-11-09 22:32 ` Norbert Preining
2014-11-10 6:07 ` Joonsoo Kim
2014-11-10 7:53 ` Vlastimil Babka [this message]
2014-11-10 8:05 ` Joonsoo Kim
2014-11-10 8:14 ` P. Christeas
2014-11-09 4:47 Hillf Danton
2014-11-09 8:22 ` P. Christeas
2014-11-09 9:35 ` Vlastimil Babka
2014-11-10 3:23 ` Hillf Danton
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=54606F02.5070808@suse.cz \
--to=vbabka@suse.cz \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=markus@trippelsdorf.de \
--cc=pavel@ucw.cz \
--cc=preining@logic.at \
--cc=rientjes@google.com \
--cc=xrg@linux.gr \
/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