From: Joonsoo Kim <iamjoonsoo.kim@lge.com>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Mel Gorman <mgorman@suse.de>, Rik van Riel <riel@redhat.com>
Subject: Re: [PATCH V2 0/6] Memory compaction efficiency improvements
Date: Fri, 13 Dec 2013 11:03:23 +0900 [thread overview]
Message-ID: <20131213020323.GB8845@lge.com> (raw)
In-Reply-To: <52A9B9A2.2050306@suse.cz>
> >>stress-highalloc
> >> 3.13-rc2 3.13-rc2 3.13-rc2 3.13-rc2 3.13-rc2
> >> 2-thp 3-thp 4-thp 5-thp 6-thp
> >>Success 1 Min 2.00 ( 0.00%) 7.00 (-250.00%) 18.00 (-800.00%) 19.00 (-850.00%) 26.00 (-1200.00%)
> >>Success 1 Mean 19.20 ( 0.00%) 17.80 ( 7.29%) 29.20 (-52.08%) 29.90 (-55.73%) 32.80 (-70.83%)
> >>Success 1 Max 27.00 ( 0.00%) 29.00 ( -7.41%) 35.00 (-29.63%) 36.00 (-33.33%) 37.00 (-37.04%)
> >>Success 2 Min 3.00 ( 0.00%) 8.00 (-166.67%) 21.00 (-600.00%) 21.00 (-600.00%) 32.00 (-966.67%)
> >>Success 2 Mean 19.30 ( 0.00%) 17.90 ( 7.25%) 32.20 (-66.84%) 32.60 (-68.91%) 35.70 (-84.97%)
> >>Success 2 Max 27.00 ( 0.00%) 30.00 (-11.11%) 36.00 (-33.33%) 37.00 (-37.04%) 39.00 (-44.44%)
> >>Success 3 Min 62.00 ( 0.00%) 62.00 ( 0.00%) 85.00 (-37.10%) 75.00 (-20.97%) 64.00 ( -3.23%)
> >>Success 3 Mean 66.30 ( 0.00%) 65.50 ( 1.21%) 85.60 (-29.11%) 83.40 (-25.79%) 83.50 (-25.94%)
> >>Success 3 Max 70.00 ( 0.00%) 69.00 ( 1.43%) 87.00 (-24.29%) 86.00 (-22.86%) 87.00 (-24.29%)
> >>
> >> 3.13-rc2 3.13-rc2 3.13-rc2 3.13-rc2 3.13-rc2
> >> 2-thp 3-thp 4-thp 5-thp 6-thp
> >>User 6547.93 6475.85 6265.54 6289.46 6189.96
> >>System 1053.42 1047.28 1043.23 1042.73 1038.73
> >>Elapsed 1835.43 1821.96 1908.67 1912.74 1956.38
> >
> >Hello, Vlastimil.
> >
> >I have some questions related to your stat, not your patchset,
> >just for curiosity. :)
> >
> >Are these results, "elapsed time" and "vmstat", for Success 3 line scenario?
>
> No that's for the whole test which does the scenarios in succession.
>
Okay!
> >If so, could you show me others?
> >I wonder why thp case consumes more system time rather than no-thp case.
>
> Unfortunately these stats are not that useful as they don't
> distinguish the 3 phases and also include what the background load
> does. They are included just to show that nothing truly dramatic is
> happening.
> So
>
> >And I found that elapsed time has no big difference between both cases,
> >roughly less than 2%. In this situation, do we get more benefits with
> >aggressive allocation like no-thp case?
>
> Elapsed time suffers from the same problem, so it's again hard to
> say how relevant it actually is to the allocator workload and how
> much to background load. It seems that the more successful allocator
> is, the longer elapsed time (in both thp and nothp case). My guess
> is that less memory available for the background load makes it
> progress slower which affects the duration of the test as a whole.
>
> I hope that in case of further compaction patches that would be
> potentially more intrusive to the its design (and not bugfixes and
> simple tweaks to the existing design as this series) I will have a
> more detailed breakdown of what time is spent where.
Okay!
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>
WARNING: multiple messages have this Message-ID (diff)
From: Joonsoo Kim <iamjoonsoo.kim@lge.com>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Mel Gorman <mgorman@suse.de>, Rik van Riel <riel@redhat.com>
Subject: Re: [PATCH V2 0/6] Memory compaction efficiency improvements
Date: Fri, 13 Dec 2013 11:03:23 +0900 [thread overview]
Message-ID: <20131213020323.GB8845@lge.com> (raw)
In-Reply-To: <52A9B9A2.2050306@suse.cz>
> >>stress-highalloc
> >> 3.13-rc2 3.13-rc2 3.13-rc2 3.13-rc2 3.13-rc2
> >> 2-thp 3-thp 4-thp 5-thp 6-thp
> >>Success 1 Min 2.00 ( 0.00%) 7.00 (-250.00%) 18.00 (-800.00%) 19.00 (-850.00%) 26.00 (-1200.00%)
> >>Success 1 Mean 19.20 ( 0.00%) 17.80 ( 7.29%) 29.20 (-52.08%) 29.90 (-55.73%) 32.80 (-70.83%)
> >>Success 1 Max 27.00 ( 0.00%) 29.00 ( -7.41%) 35.00 (-29.63%) 36.00 (-33.33%) 37.00 (-37.04%)
> >>Success 2 Min 3.00 ( 0.00%) 8.00 (-166.67%) 21.00 (-600.00%) 21.00 (-600.00%) 32.00 (-966.67%)
> >>Success 2 Mean 19.30 ( 0.00%) 17.90 ( 7.25%) 32.20 (-66.84%) 32.60 (-68.91%) 35.70 (-84.97%)
> >>Success 2 Max 27.00 ( 0.00%) 30.00 (-11.11%) 36.00 (-33.33%) 37.00 (-37.04%) 39.00 (-44.44%)
> >>Success 3 Min 62.00 ( 0.00%) 62.00 ( 0.00%) 85.00 (-37.10%) 75.00 (-20.97%) 64.00 ( -3.23%)
> >>Success 3 Mean 66.30 ( 0.00%) 65.50 ( 1.21%) 85.60 (-29.11%) 83.40 (-25.79%) 83.50 (-25.94%)
> >>Success 3 Max 70.00 ( 0.00%) 69.00 ( 1.43%) 87.00 (-24.29%) 86.00 (-22.86%) 87.00 (-24.29%)
> >>
> >> 3.13-rc2 3.13-rc2 3.13-rc2 3.13-rc2 3.13-rc2
> >> 2-thp 3-thp 4-thp 5-thp 6-thp
> >>User 6547.93 6475.85 6265.54 6289.46 6189.96
> >>System 1053.42 1047.28 1043.23 1042.73 1038.73
> >>Elapsed 1835.43 1821.96 1908.67 1912.74 1956.38
> >
> >Hello, Vlastimil.
> >
> >I have some questions related to your stat, not your patchset,
> >just for curiosity. :)
> >
> >Are these results, "elapsed time" and "vmstat", for Success 3 line scenario?
>
> No that's for the whole test which does the scenarios in succession.
>
Okay!
> >If so, could you show me others?
> >I wonder why thp case consumes more system time rather than no-thp case.
>
> Unfortunately these stats are not that useful as they don't
> distinguish the 3 phases and also include what the background load
> does. They are included just to show that nothing truly dramatic is
> happening.
> So
>
> >And I found that elapsed time has no big difference between both cases,
> >roughly less than 2%. In this situation, do we get more benefits with
> >aggressive allocation like no-thp case?
>
> Elapsed time suffers from the same problem, so it's again hard to
> say how relevant it actually is to the allocator workload and how
> much to background load. It seems that the more successful allocator
> is, the longer elapsed time (in both thp and nothp case). My guess
> is that less memory available for the background load makes it
> progress slower which affects the duration of the test as a whole.
>
> I hope that in case of further compaction patches that would be
> potentially more intrusive to the its design (and not bugfixes and
> simple tweaks to the existing design as this series) I will have a
> more detailed breakdown of what time is spent where.
Okay!
Thanks.
next prev parent reply other threads:[~2013-12-13 2:00 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-11 10:24 [PATCH V2 0/6] Memory compaction efficiency improvements Vlastimil Babka
2013-12-11 10:24 ` Vlastimil Babka
2013-12-11 10:24 ` [PATCH V2 1/6] mm: compaction: trace compaction begin and end Vlastimil Babka
2013-12-11 10:24 ` Vlastimil Babka
2013-12-11 10:24 ` [PATCH V2 2/6] mm: compaction: encapsulate defer reset logic Vlastimil Babka
2013-12-11 10:24 ` Vlastimil Babka
2013-12-11 10:24 ` [PATCH V2 3/6] mm: compaction: reset cached scanner pfn's before reading them Vlastimil Babka
2013-12-11 10:24 ` Vlastimil Babka
2013-12-11 10:24 ` [PATCH V2 4/6] mm: compaction: detect when scanners meet in isolate_freepages Vlastimil Babka
2013-12-11 10:24 ` Vlastimil Babka
2013-12-11 10:24 ` [PATCH V2 5/6] mm: compaction: do not mark unmovable pageblocks as skipped in async compaction Vlastimil Babka
2013-12-11 10:24 ` Vlastimil Babka
2013-12-11 10:24 ` [PATCH V2 6/6] mm: compaction: reset scanner positions immediately when they meet Vlastimil Babka
2013-12-11 10:24 ` Vlastimil Babka
2013-12-12 6:12 ` [PATCH V2 0/6] Memory compaction efficiency improvements Joonsoo Kim
2013-12-12 6:12 ` Joonsoo Kim
2013-12-12 13:26 ` Vlastimil Babka
2013-12-12 13:26 ` Vlastimil Babka
2013-12-13 2:03 ` Joonsoo Kim [this message]
2013-12-13 2:03 ` Joonsoo 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=20131213020323.GB8845@lge.com \
--to=iamjoonsoo.kim@lge.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=riel@redhat.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.