From: Gioh Kim <gioh.kim@lge.com>
To: Vlastimil Babka <vbabka@suse.cz>,
akpm@linux-foundation.org, rientjes@google.com,
iamjoonsoo.kim@lge.com, mgorman@suse.de
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, gunho.lee@lge.com
Subject: Re: [PATCH] [RFC] mm/compaction: initialize compaction information
Date: Fri, 20 Mar 2015 08:33:37 +0900 [thread overview]
Message-ID: <550B5CD1.5010306@lge.com> (raw)
In-Reply-To: <550A9086.3080508@suse.cz>
2015-03-19 i??i?? 6:01i?? Vlastimil Babka i?'(e??) i?' e,?:
> On 03/19/2015 09:52 AM, Gioh Kim wrote:
>>
>>
>> 2015-03-19 i??i?? 5:41i?? Vlastimil Babka i?'(e??) i?' e,?:
>>> On 03/19/2015 06:30 AM, Gioh Kim wrote:
>>>
>>> The code below this comment already does the initialization if the cached values
>>> are outside zone boundaries (e.g. due to not being initialized). So if I go
>>> through what your __reset_isolation_suitable(zone) call possibly fixes:
>>>
>>> - the code below comment should take care of zone->compact_cached_migrate_pfn
>>> and zone->compact_cached_free_pfn.
>>> - the value of zone->compact_blockskip_flush shouldn't affect whether compaction
>>> is done.
>>> - the state of pageblock_skip bits shouldn't matter for compaction via
>>> /proc/sys... as that sets ignore_skip_hint = true
>>>
>>> It might be perhaps possible that the cached scanner positions are close to
>>> meeting and compaction occurs but doesn't process much. That would be also true
>>> if both were zero, but at least on my x86 system, lowest zone's start_pfn is 1
>>> so that would be detected and corrected. Maybe it is zero on yours though? (ARM?).
>>
>> YES, it is. As comment above, my platform is based on ARM.
>
> Ah, I see.
>
>> zone's start_pfn is 0.
>
> OK, good to know that's possible. In that case it's clear that the proper
> initialization doesn't happen, and __compact_finished() decides that scanners
> have already met at pfn 0.
>
>>>
>>> So in any case, the problem should be identified in more detail so we know the
>>> fix is not accidental. It could be also worthwile to always reset scanner
>>> positions when doing a /proc triggered compaction, so it's not depending on what
>>> happened before.
>>>
>>
>> Excuse my poor english.
>> I cannot catch exactly what you want.
>> Is this what you want? This resets the position if compaction is started via /proc.
>
> Yes that's right, but..
>
>> diff --git a/mm/compaction.c b/mm/compaction.c
>> index 8c0d945..827ec06 100644
>> --- a/mm/compaction.c
>> +++ b/mm/compaction.c
>> @@ -1587,8 +1587,10 @@ static void __compact_pgdat(pg_data_t *pgdat, struct compact_control *cc)
>> INIT_LIST_HEAD(&cc->freepages);
>> INIT_LIST_HEAD(&cc->migratepages);
>>
>> - if (cc->order == -1 || !compaction_deferred(zone, cc->order))
>> + if (cc->order == -1 || !compaction_deferred(zone, cc->order)) {
>> + __reset_isolation_suitable(zone);
>
> This will also trigger reset when called from kswapd through compact_pgdat() and
> !compaction_deferred() is true.
> The reset should be restricted to cc->order == -1 which only happens from /proc
> trigger.
>
>> compact_zone(zone, cc);
>> + }
>>
>> if (cc->order > 0) {
>> if (zone_watermark_ok(zone, cc->order,
>>
>
>
I've not been familiar with compaction code.
I think cc->order is -1 only if __compact_pgdat is called via /proc.
This is ugly but I don't have better solution.
Do you have better idea?
diff --git a/mm/compaction.c b/mm/compaction.c
index 8c0d945..5b4e255 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -1587,6 +1587,9 @@ static void __compact_pgdat(pg_data_t *pgdat, struct compact_control *cc)
INIT_LIST_HEAD(&cc->freepages);
INIT_LIST_HEAD(&cc->migratepages);
+ if (cc->order == -1)
+ __reset_isolation_suitable(zone);
+
if (cc->order == -1 || !compaction_deferred(zone, cc->order))
compact_zone(zone, cc);
--
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: Gioh Kim <gioh.kim@lge.com>
To: Vlastimil Babka <vbabka@suse.cz>,
akpm@linux-foundation.org, rientjes@google.com,
iamjoonsoo.kim@lge.com, mgorman@suse.de
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, gunho.lee@lge.com
Subject: Re: [PATCH] [RFC] mm/compaction: initialize compaction information
Date: Fri, 20 Mar 2015 08:33:37 +0900 [thread overview]
Message-ID: <550B5CD1.5010306@lge.com> (raw)
In-Reply-To: <550A9086.3080508@suse.cz>
2015-03-19 오후 6:01에 Vlastimil Babka 이(가) 쓴 글:
> On 03/19/2015 09:52 AM, Gioh Kim wrote:
>>
>>
>> 2015-03-19 오후 5:41에 Vlastimil Babka 이(가) 쓴 글:
>>> On 03/19/2015 06:30 AM, Gioh Kim wrote:
>>>
>>> The code below this comment already does the initialization if the cached values
>>> are outside zone boundaries (e.g. due to not being initialized). So if I go
>>> through what your __reset_isolation_suitable(zone) call possibly fixes:
>>>
>>> - the code below comment should take care of zone->compact_cached_migrate_pfn
>>> and zone->compact_cached_free_pfn.
>>> - the value of zone->compact_blockskip_flush shouldn't affect whether compaction
>>> is done.
>>> - the state of pageblock_skip bits shouldn't matter for compaction via
>>> /proc/sys... as that sets ignore_skip_hint = true
>>>
>>> It might be perhaps possible that the cached scanner positions are close to
>>> meeting and compaction occurs but doesn't process much. That would be also true
>>> if both were zero, but at least on my x86 system, lowest zone's start_pfn is 1
>>> so that would be detected and corrected. Maybe it is zero on yours though? (ARM?).
>>
>> YES, it is. As comment above, my platform is based on ARM.
>
> Ah, I see.
>
>> zone's start_pfn is 0.
>
> OK, good to know that's possible. In that case it's clear that the proper
> initialization doesn't happen, and __compact_finished() decides that scanners
> have already met at pfn 0.
>
>>>
>>> So in any case, the problem should be identified in more detail so we know the
>>> fix is not accidental. It could be also worthwile to always reset scanner
>>> positions when doing a /proc triggered compaction, so it's not depending on what
>>> happened before.
>>>
>>
>> Excuse my poor english.
>> I cannot catch exactly what you want.
>> Is this what you want? This resets the position if compaction is started via /proc.
>
> Yes that's right, but..
>
>> diff --git a/mm/compaction.c b/mm/compaction.c
>> index 8c0d945..827ec06 100644
>> --- a/mm/compaction.c
>> +++ b/mm/compaction.c
>> @@ -1587,8 +1587,10 @@ static void __compact_pgdat(pg_data_t *pgdat, struct compact_control *cc)
>> INIT_LIST_HEAD(&cc->freepages);
>> INIT_LIST_HEAD(&cc->migratepages);
>>
>> - if (cc->order == -1 || !compaction_deferred(zone, cc->order))
>> + if (cc->order == -1 || !compaction_deferred(zone, cc->order)) {
>> + __reset_isolation_suitable(zone);
>
> This will also trigger reset when called from kswapd through compact_pgdat() and
> !compaction_deferred() is true.
> The reset should be restricted to cc->order == -1 which only happens from /proc
> trigger.
>
>> compact_zone(zone, cc);
>> + }
>>
>> if (cc->order > 0) {
>> if (zone_watermark_ok(zone, cc->order,
>>
>
>
I've not been familiar with compaction code.
I think cc->order is -1 only if __compact_pgdat is called via /proc.
This is ugly but I don't have better solution.
Do you have better idea?
diff --git a/mm/compaction.c b/mm/compaction.c
index 8c0d945..5b4e255 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -1587,6 +1587,9 @@ static void __compact_pgdat(pg_data_t *pgdat, struct compact_control *cc)
INIT_LIST_HEAD(&cc->freepages);
INIT_LIST_HEAD(&cc->migratepages);
+ if (cc->order == -1)
+ __reset_isolation_suitable(zone);
+
if (cc->order == -1 || !compaction_deferred(zone, cc->order))
compact_zone(zone, cc);
next prev parent reply other threads:[~2015-03-19 23:33 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-19 5:30 [PATCH] [RFC] mm/compaction: initialize compaction information Gioh Kim
2015-03-19 5:30 ` Gioh Kim
2015-03-19 8:41 ` Vlastimil Babka
2015-03-19 8:41 ` Vlastimil Babka
2015-03-19 8:52 ` Gioh Kim
2015-03-19 8:52 ` Gioh Kim
2015-03-19 9:01 ` Vlastimil Babka
2015-03-19 9:01 ` Vlastimil Babka
2015-03-19 23:33 ` Gioh Kim [this message]
2015-03-19 23:33 ` Gioh Kim
2015-03-20 7:51 ` Vlastimil Babka
2015-03-20 7:51 ` Vlastimil Babka
2015-03-20 13:00 ` [PATCH][RFCv2] mm/compaction: reset compaction scanner positions Gioh Kim
2015-03-20 13:00 ` Gioh Kim
2015-03-20 13:49 ` Vlastimil Babka
2015-03-20 13:49 ` Vlastimil Babka
2015-03-21 11:53 ` Gioh Kim
2015-03-21 11:53 ` Gioh Kim
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=550B5CD1.5010306@lge.com \
--to=gioh.kim@lge.com \
--cc=akpm@linux-foundation.org \
--cc=gunho.lee@lge.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=rientjes@google.com \
--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 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.