From: Yuanhan Liu <yuanhan.liu@linux.intel.com>
To: Mel Gorman <mgorman@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Hugh Dickins <hughd@google.com>,
Tim Chen <tim.c.chen@linux.intel.com>,
Dave Chinner <david@fromorbit.com>,
Yuanhan Liu <yuanhan.liu@linux.intel.com>,
Bob Liu <bob.liu@oracle.com>, Jan Kara <jack@suse.cz>,
Rik van Riel <riel@redhat.com>, Mel Gorman <mgorman@suse.de>,
Linux Kernel <linux-kernel@vger.kernel.org>,
Linux-MM <linux-mm@kvack.org>,
Linux-FSDevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH 0/3] Shrinkers and proportional reclaim
Date: Fri, 23 May 2014 00:14:16 +0800 [thread overview]
Message-ID: <20140522161416.GD25013@yliu-dev.sh.intel.com> (raw)
In-Reply-To: <1400749779-24879-1-git-send-email-mgorman@suse.de>
On Thu, May 22, 2014 at 10:09:36AM +0100, Mel Gorman wrote:
> This series is aimed at regressions noticed during reclaim activity. The
> first two patches are shrinker patches that were posted ages ago but never
> merged for reasons that are unclear to me. I'm posting them again to see if
> there was a reason they were dropped or if they just got lost. Dave? Time?
> The last patch adjusts proportional reclaim. Yuanhan Liu, can you retest
> the vm scalability test cases on a larger machine? Hugh, does this work
> for you on the memcg test cases?
Sure, and here is the result. I applied these 3 patches on v3.15-rc6,
and head commit is 60c10afd. e82e0561 is the old commit that introduced
the regression. The testserver has 512G memory and 120 CPU.
It's a simple result; if you need more data, I can gather them and send
it to you tomorrow:
e82e0561 v3.15-rc6 60c10afd
----------------------------------------
18560785 12232122 38868453
-34% +109
As you can see, the performance is back, and it is way much better ;)
--yliu
>
> Based on ext4, I get the following results but unfortunately my larger test
> machines are all unavailable so this is based on a relatively small machine.
>
> postmark
> 3.15.0-rc5 3.15.0-rc5
> vanilla proportion-v1r4
> Ops/sec Transactions 21.00 ( 0.00%) 25.00 ( 19.05%)
> Ops/sec FilesCreate 39.00 ( 0.00%) 45.00 ( 15.38%)
> Ops/sec CreateTransact 10.00 ( 0.00%) 12.00 ( 20.00%)
> Ops/sec FilesDeleted 6202.00 ( 0.00%) 6202.00 ( 0.00%)
> Ops/sec DeleteTransact 11.00 ( 0.00%) 12.00 ( 9.09%)
> Ops/sec DataRead/MB 25.97 ( 0.00%) 30.02 ( 15.59%)
> Ops/sec DataWrite/MB 49.99 ( 0.00%) 57.78 ( 15.58%)
>
> ffsb (mail server simulator)
> 3.15.0-rc5 3.15.0-rc5
> vanilla proportion-v1r4
> Ops/sec readall 9402.63 ( 0.00%) 9805.74 ( 4.29%)
> Ops/sec create 4695.45 ( 0.00%) 4781.39 ( 1.83%)
> Ops/sec delete 173.72 ( 0.00%) 177.23 ( 2.02%)
> Ops/sec Transactions 14271.80 ( 0.00%) 14764.37 ( 3.45%)
> Ops/sec Read 37.00 ( 0.00%) 38.50 ( 4.05%)
> Ops/sec Write 18.20 ( 0.00%) 18.50 ( 1.65%)
>
> dd of a large file
> 3.15.0-rc5 3.15.0-rc5
> vanilla proportion-v1r4
> WallTime DownloadTar 75.00 ( 0.00%) 61.00 ( 18.67%)
> WallTime DD 423.00 ( 0.00%) 401.00 ( 5.20%)
> WallTime Delete 2.00 ( 0.00%) 5.00 (-150.00%)
>
> stutter (times mmap latency during large amounts of IO)
>
> 3.15.0-rc5 3.15.0-rc5
> vanilla proportion-v1r4
> Unit >5ms Delays 80252.0000 ( 0.00%) 81523.0000 ( -1.58%)
> Unit Mmap min 8.2118 ( 0.00%) 8.3206 ( -1.33%)
> Unit Mmap mean 17.4614 ( 0.00%) 17.2868 ( 1.00%)
> Unit Mmap stddev 24.9059 ( 0.00%) 34.6771 (-39.23%)
> Unit Mmap max 2811.6433 ( 0.00%) 2645.1398 ( 5.92%)
> Unit Mmap 90% 20.5098 ( 0.00%) 18.3105 ( 10.72%)
> Unit Mmap 93% 22.9180 ( 0.00%) 20.1751 ( 11.97%)
> Unit Mmap 95% 25.2114 ( 0.00%) 22.4988 ( 10.76%)
> Unit Mmap 99% 46.1430 ( 0.00%) 43.5952 ( 5.52%)
> Unit Ideal Tput 85.2623 ( 0.00%) 78.8906 ( 7.47%)
> Unit Tput min 44.0666 ( 0.00%) 43.9609 ( 0.24%)
> Unit Tput mean 45.5646 ( 0.00%) 45.2009 ( 0.80%)
> Unit Tput stddev 0.9318 ( 0.00%) 1.1084 (-18.95%)
> Unit Tput max 46.7375 ( 0.00%) 46.7539 ( -0.04%)
>
> fs/super.c | 16 +++++++++-------
> mm/vmscan.c | 36 +++++++++++++++++++++++++-----------
> 2 files changed, 34 insertions(+), 18 deletions(-)
>
> --
> 1.8.4.5
--
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: Yuanhan Liu <yuanhan.liu@linux.intel.com>
To: Mel Gorman <mgorman@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Hugh Dickins <hughd@google.com>,
Tim Chen <tim.c.chen@linux.intel.com>,
Dave Chinner <david@fromorbit.com>,
Yuanhan Liu <yuanhan.liu@linux.intel.com>,
Bob Liu <bob.liu@oracle.com>, Jan Kara <jack@suse.cz>,
Rik van Riel <riel@redhat.com>,
Linux Kernel <linux-kernel@vger.kernel.org>,
Linux-MM <linux-mm@kvack.org>,
Linux-FSDevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH 0/3] Shrinkers and proportional reclaim
Date: Fri, 23 May 2014 00:14:16 +0800 [thread overview]
Message-ID: <20140522161416.GD25013@yliu-dev.sh.intel.com> (raw)
In-Reply-To: <1400749779-24879-1-git-send-email-mgorman@suse.de>
On Thu, May 22, 2014 at 10:09:36AM +0100, Mel Gorman wrote:
> This series is aimed at regressions noticed during reclaim activity. The
> first two patches are shrinker patches that were posted ages ago but never
> merged for reasons that are unclear to me. I'm posting them again to see if
> there was a reason they were dropped or if they just got lost. Dave? Time?
> The last patch adjusts proportional reclaim. Yuanhan Liu, can you retest
> the vm scalability test cases on a larger machine? Hugh, does this work
> for you on the memcg test cases?
Sure, and here is the result. I applied these 3 patches on v3.15-rc6,
and head commit is 60c10afd. e82e0561 is the old commit that introduced
the regression. The testserver has 512G memory and 120 CPU.
It's a simple result; if you need more data, I can gather them and send
it to you tomorrow:
e82e0561 v3.15-rc6 60c10afd
----------------------------------------
18560785 12232122 38868453
-34% +109
As you can see, the performance is back, and it is way much better ;)
--yliu
>
> Based on ext4, I get the following results but unfortunately my larger test
> machines are all unavailable so this is based on a relatively small machine.
>
> postmark
> 3.15.0-rc5 3.15.0-rc5
> vanilla proportion-v1r4
> Ops/sec Transactions 21.00 ( 0.00%) 25.00 ( 19.05%)
> Ops/sec FilesCreate 39.00 ( 0.00%) 45.00 ( 15.38%)
> Ops/sec CreateTransact 10.00 ( 0.00%) 12.00 ( 20.00%)
> Ops/sec FilesDeleted 6202.00 ( 0.00%) 6202.00 ( 0.00%)
> Ops/sec DeleteTransact 11.00 ( 0.00%) 12.00 ( 9.09%)
> Ops/sec DataRead/MB 25.97 ( 0.00%) 30.02 ( 15.59%)
> Ops/sec DataWrite/MB 49.99 ( 0.00%) 57.78 ( 15.58%)
>
> ffsb (mail server simulator)
> 3.15.0-rc5 3.15.0-rc5
> vanilla proportion-v1r4
> Ops/sec readall 9402.63 ( 0.00%) 9805.74 ( 4.29%)
> Ops/sec create 4695.45 ( 0.00%) 4781.39 ( 1.83%)
> Ops/sec delete 173.72 ( 0.00%) 177.23 ( 2.02%)
> Ops/sec Transactions 14271.80 ( 0.00%) 14764.37 ( 3.45%)
> Ops/sec Read 37.00 ( 0.00%) 38.50 ( 4.05%)
> Ops/sec Write 18.20 ( 0.00%) 18.50 ( 1.65%)
>
> dd of a large file
> 3.15.0-rc5 3.15.0-rc5
> vanilla proportion-v1r4
> WallTime DownloadTar 75.00 ( 0.00%) 61.00 ( 18.67%)
> WallTime DD 423.00 ( 0.00%) 401.00 ( 5.20%)
> WallTime Delete 2.00 ( 0.00%) 5.00 (-150.00%)
>
> stutter (times mmap latency during large amounts of IO)
>
> 3.15.0-rc5 3.15.0-rc5
> vanilla proportion-v1r4
> Unit >5ms Delays 80252.0000 ( 0.00%) 81523.0000 ( -1.58%)
> Unit Mmap min 8.2118 ( 0.00%) 8.3206 ( -1.33%)
> Unit Mmap mean 17.4614 ( 0.00%) 17.2868 ( 1.00%)
> Unit Mmap stddev 24.9059 ( 0.00%) 34.6771 (-39.23%)
> Unit Mmap max 2811.6433 ( 0.00%) 2645.1398 ( 5.92%)
> Unit Mmap 90% 20.5098 ( 0.00%) 18.3105 ( 10.72%)
> Unit Mmap 93% 22.9180 ( 0.00%) 20.1751 ( 11.97%)
> Unit Mmap 95% 25.2114 ( 0.00%) 22.4988 ( 10.76%)
> Unit Mmap 99% 46.1430 ( 0.00%) 43.5952 ( 5.52%)
> Unit Ideal Tput 85.2623 ( 0.00%) 78.8906 ( 7.47%)
> Unit Tput min 44.0666 ( 0.00%) 43.9609 ( 0.24%)
> Unit Tput mean 45.5646 ( 0.00%) 45.2009 ( 0.80%)
> Unit Tput stddev 0.9318 ( 0.00%) 1.1084 (-18.95%)
> Unit Tput max 46.7375 ( 0.00%) 46.7539 ( -0.04%)
>
> fs/super.c | 16 +++++++++-------
> mm/vmscan.c | 36 +++++++++++++++++++++++++-----------
> 2 files changed, 34 insertions(+), 18 deletions(-)
>
> --
> 1.8.4.5
--
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: Yuanhan Liu <yuanhan.liu@linux.intel.com>
To: Mel Gorman <mgorman@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Hugh Dickins <hughd@google.com>,
Tim Chen <tim.c.chen@linux.intel.com>,
Dave Chinner <david@fromorbit.com>,
Yuanhan Liu <yuanhan.liu@linux.intel.com>,
Bob Liu <bob.liu@oracle.com>, Jan Kara <jack@suse.cz>,
Rik van Riel <riel@redhat.com>, Mel Gorman <mgorman@suse.de>,
Linux Kernel <linux-kernel@vger.kernel.org>,
Linux-MM <linux-mm@kvack.org>,
Linux-FSDevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH 0/3] Shrinkers and proportional reclaim
Date: Fri, 23 May 2014 00:14:16 +0800 [thread overview]
Message-ID: <20140522161416.GD25013@yliu-dev.sh.intel.com> (raw)
In-Reply-To: <1400749779-24879-1-git-send-email-mgorman@suse.de>
On Thu, May 22, 2014 at 10:09:36AM +0100, Mel Gorman wrote:
> This series is aimed at regressions noticed during reclaim activity. The
> first two patches are shrinker patches that were posted ages ago but never
> merged for reasons that are unclear to me. I'm posting them again to see if
> there was a reason they were dropped or if they just got lost. Dave? Time?
> The last patch adjusts proportional reclaim. Yuanhan Liu, can you retest
> the vm scalability test cases on a larger machine? Hugh, does this work
> for you on the memcg test cases?
Sure, and here is the result. I applied these 3 patches on v3.15-rc6,
and head commit is 60c10afd. e82e0561 is the old commit that introduced
the regression. The testserver has 512G memory and 120 CPU.
It's a simple result; if you need more data, I can gather them and send
it to you tomorrow:
e82e0561 v3.15-rc6 60c10afd
----------------------------------------
18560785 12232122 38868453
-34% +109
As you can see, the performance is back, and it is way much better ;)
--yliu
>
> Based on ext4, I get the following results but unfortunately my larger test
> machines are all unavailable so this is based on a relatively small machine.
>
> postmark
> 3.15.0-rc5 3.15.0-rc5
> vanilla proportion-v1r4
> Ops/sec Transactions 21.00 ( 0.00%) 25.00 ( 19.05%)
> Ops/sec FilesCreate 39.00 ( 0.00%) 45.00 ( 15.38%)
> Ops/sec CreateTransact 10.00 ( 0.00%) 12.00 ( 20.00%)
> Ops/sec FilesDeleted 6202.00 ( 0.00%) 6202.00 ( 0.00%)
> Ops/sec DeleteTransact 11.00 ( 0.00%) 12.00 ( 9.09%)
> Ops/sec DataRead/MB 25.97 ( 0.00%) 30.02 ( 15.59%)
> Ops/sec DataWrite/MB 49.99 ( 0.00%) 57.78 ( 15.58%)
>
> ffsb (mail server simulator)
> 3.15.0-rc5 3.15.0-rc5
> vanilla proportion-v1r4
> Ops/sec readall 9402.63 ( 0.00%) 9805.74 ( 4.29%)
> Ops/sec create 4695.45 ( 0.00%) 4781.39 ( 1.83%)
> Ops/sec delete 173.72 ( 0.00%) 177.23 ( 2.02%)
> Ops/sec Transactions 14271.80 ( 0.00%) 14764.37 ( 3.45%)
> Ops/sec Read 37.00 ( 0.00%) 38.50 ( 4.05%)
> Ops/sec Write 18.20 ( 0.00%) 18.50 ( 1.65%)
>
> dd of a large file
> 3.15.0-rc5 3.15.0-rc5
> vanilla proportion-v1r4
> WallTime DownloadTar 75.00 ( 0.00%) 61.00 ( 18.67%)
> WallTime DD 423.00 ( 0.00%) 401.00 ( 5.20%)
> WallTime Delete 2.00 ( 0.00%) 5.00 (-150.00%)
>
> stutter (times mmap latency during large amounts of IO)
>
> 3.15.0-rc5 3.15.0-rc5
> vanilla proportion-v1r4
> Unit >5ms Delays 80252.0000 ( 0.00%) 81523.0000 ( -1.58%)
> Unit Mmap min 8.2118 ( 0.00%) 8.3206 ( -1.33%)
> Unit Mmap mean 17.4614 ( 0.00%) 17.2868 ( 1.00%)
> Unit Mmap stddev 24.9059 ( 0.00%) 34.6771 (-39.23%)
> Unit Mmap max 2811.6433 ( 0.00%) 2645.1398 ( 5.92%)
> Unit Mmap 90% 20.5098 ( 0.00%) 18.3105 ( 10.72%)
> Unit Mmap 93% 22.9180 ( 0.00%) 20.1751 ( 11.97%)
> Unit Mmap 95% 25.2114 ( 0.00%) 22.4988 ( 10.76%)
> Unit Mmap 99% 46.1430 ( 0.00%) 43.5952 ( 5.52%)
> Unit Ideal Tput 85.2623 ( 0.00%) 78.8906 ( 7.47%)
> Unit Tput min 44.0666 ( 0.00%) 43.9609 ( 0.24%)
> Unit Tput mean 45.5646 ( 0.00%) 45.2009 ( 0.80%)
> Unit Tput stddev 0.9318 ( 0.00%) 1.1084 (-18.95%)
> Unit Tput max 46.7375 ( 0.00%) 46.7539 ( -0.04%)
>
> fs/super.c | 16 +++++++++-------
> mm/vmscan.c | 36 +++++++++++++++++++++++++-----------
> 2 files changed, 34 insertions(+), 18 deletions(-)
>
> --
> 1.8.4.5
next prev parent reply other threads:[~2014-05-22 16:14 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-22 9:09 [PATCH 0/3] Shrinkers and proportional reclaim Mel Gorman
2014-05-22 9:09 ` [PATCH 1/3] fs/superblock: Unregister sb shrinker before ->kill_sb() Mel Gorman
2014-05-22 15:52 ` Rik van Riel
2014-05-22 15:52 ` Rik van Riel
2014-05-22 9:09 ` [PATCH 2/3] fs/superblock: Avoid locking counting inodes and dentries before reclaiming them Mel Gorman
2014-05-22 15:59 ` Rik van Riel
2014-05-22 15:59 ` Rik van Riel
2014-05-22 9:09 ` [PATCH 3/3] mm: vmscan: Use proportional scanning during direct reclaim and full scan at DEF_PRIORITY Mel Gorman
2014-05-22 16:04 ` Rik van Riel
2014-05-22 16:04 ` Rik van Riel
2014-05-22 16:14 ` Yuanhan Liu [this message]
2014-05-22 16:14 ` [PATCH 0/3] Shrinkers and proportional reclaim Yuanhan Liu
2014-05-22 16:14 ` Yuanhan Liu
2014-05-22 16:30 ` Mel Gorman
2014-05-22 16:30 ` Mel Gorman
2014-05-23 2:43 ` Yuanhan Liu
2014-05-23 2:43 ` Yuanhan Liu
2014-05-22 17:22 ` Tim Chen
2014-05-22 17:22 ` Tim Chen
2014-05-26 21:44 ` Hugh Dickins
2014-05-26 21:44 ` Hugh Dickins
2014-05-27 2:37 ` Dave Chinner
2014-05-27 2:37 ` Dave Chinner
2014-05-27 21:17 ` Hugh Dickins
2014-05-27 21:17 ` Hugh Dickins
2014-05-27 23:02 ` Konstantin Khlebnikov
2014-05-27 23:02 ` Konstantin Khlebnikov
2014-05-27 23:19 ` Hugh Dickins
2014-05-27 23:19 ` Hugh Dickins
2014-05-28 1:37 ` Dave Chinner
2014-05-28 1:37 ` Dave Chinner
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=20140522161416.GD25013@yliu-dev.sh.intel.com \
--to=yuanhan.liu@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=bob.liu@oracle.com \
--cc=david@fromorbit.com \
--cc=hannes@cmpxchg.org \
--cc=hughd@google.com \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=riel@redhat.com \
--cc=tim.c.chen@linux.intel.com \
/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.