All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Michal Hocko <mhocko@suse.cz>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Johannes Weiner <hannes@cmpxchg.org>, Mel Gorman <mel@csn.ul.ie>,
	Minchan Kim <minchan@kernel.org>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	Rik van Riel <riel@redhat.com>
Subject: Re: [PATCH] mm: consider all swapped back pages in used-once logic
Date: Thu, 17 May 2012 13:23:24 -0700	[thread overview]
Message-ID: <20120517132324.e9bf9fc8.akpm@linux-foundation.org> (raw)
In-Reply-To: <20120517121049.GA11018@tiehlicka.suse.cz>

On Thu, 17 May 2012 14:10:49 +0200
Michal Hocko <mhocko@suse.cz> wrote:

> > > This patch fixes a regression introduced by this commit for heavy shmem
> > 
> > A performance regression, specifically.
> > 
> > Are you able to quantify it?
> 
> The customer's workload is shmem backed database (80% of RAM) and
> they are measuring transactions/s with an IO in the background (20%).
> Transactions touch more or less random rows in the table.
> The rate goes down drastically when we start swapping out memory.
> 
> Numbers are more descriptive (without the patch is 100%, with 5
> representative runs)
> Average rate	315.83%
> Best rate	131.76%
> Worst rate	641.25%
> 
> Standard deviation (calibrated to average) is ~4% while without the
> patch we are at 62.82%. 
> The big variance without the patch is caused by the excessive swapping
> which doesn't occur with the patch applied.
> 
> * Worst run (100%) compared to a random run with the patch
> pgpgin	pswpin	pswpout	pgmajfault
> 1.58%	0.00%	0.01%	0.22%
> 
> Average size of the LRU lists:
> nr_inactive_anon nr_active_anon nr_inactive_file nr_active_file
> 52.91%           7234.72%       249.39%          126.64%
> 
> * Best run
> pgpgin	pswpin	pswpout	pgmajfault
> 3.37%	0.00%	0.11%	0.39%
> 
> nr_inactive_anon nr_active_anon nr_inactive_file nr_active_file
> 49.85%           3868.74%       175.03%          121.27%

I turned the above into this soundbite:

: The customer's workload is shmem backed database (80% of RAM) and they are
: measuring transactions/s with an IO in the background (20%).  Transactions
: touch more or less random rows in the table.  Total runtime was
: approximately tripled by commit 64574746 and this patch restores the
: previous throughput levels.

Was that truthful?

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: Michal Hocko <mhocko@suse.cz>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Johannes Weiner <hannes@cmpxchg.org>, Mel Gorman <mel@csn.ul.ie>,
	Minchan Kim <minchan@kernel.org>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	Rik van Riel <riel@redhat.com>
Subject: Re: [PATCH] mm: consider all swapped back pages in used-once logic
Date: Thu, 17 May 2012 13:23:24 -0700	[thread overview]
Message-ID: <20120517132324.e9bf9fc8.akpm@linux-foundation.org> (raw)
In-Reply-To: <20120517121049.GA11018@tiehlicka.suse.cz>

On Thu, 17 May 2012 14:10:49 +0200
Michal Hocko <mhocko@suse.cz> wrote:

> > > This patch fixes a regression introduced by this commit for heavy shmem
> > 
> > A performance regression, specifically.
> > 
> > Are you able to quantify it?
> 
> The customer's workload is shmem backed database (80% of RAM) and
> they are measuring transactions/s with an IO in the background (20%).
> Transactions touch more or less random rows in the table.
> The rate goes down drastically when we start swapping out memory.
> 
> Numbers are more descriptive (without the patch is 100%, with 5
> representative runs)
> Average rate	315.83%
> Best rate	131.76%
> Worst rate	641.25%
> 
> Standard deviation (calibrated to average) is ~4% while without the
> patch we are at 62.82%. 
> The big variance without the patch is caused by the excessive swapping
> which doesn't occur with the patch applied.
> 
> * Worst run (100%) compared to a random run with the patch
> pgpgin	pswpin	pswpout	pgmajfault
> 1.58%	0.00%	0.01%	0.22%
> 
> Average size of the LRU lists:
> nr_inactive_anon nr_active_anon nr_inactive_file nr_active_file
> 52.91%           7234.72%       249.39%          126.64%
> 
> * Best run
> pgpgin	pswpin	pswpout	pgmajfault
> 3.37%	0.00%	0.11%	0.39%
> 
> nr_inactive_anon nr_active_anon nr_inactive_file nr_active_file
> 49.85%           3868.74%       175.03%          121.27%

I turned the above into this soundbite:

: The customer's workload is shmem backed database (80% of RAM) and they are
: measuring transactions/s with an IO in the background (20%).  Transactions
: touch more or less random rows in the table.  Total runtime was
: approximately tripled by commit 64574746 and this patch restores the
: previous throughput levels.

Was that truthful?

  reply	other threads:[~2012-05-17 20:23 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-17  9:13 [PATCH] mm: consider all swapped back pages in used-once logic Michal Hocko
2012-05-17  9:13 ` Michal Hocko
2012-05-17  9:24 ` Andrew Morton
2012-05-17  9:24   ` Andrew Morton
2012-05-17 12:10   ` Michal Hocko
2012-05-17 12:10     ` Michal Hocko
2012-05-17 20:23     ` Andrew Morton [this message]
2012-05-17 20:23       ` Andrew Morton
2012-05-18  6:50       ` Michal Hocko
2012-05-18  6:50         ` Michal Hocko
2012-05-17 13:14 ` Rik van Riel
2012-05-17 13:14   ` Rik van Riel
2012-05-17 19:54 ` Johannes Weiner
2012-05-17 19:54   ` Johannes Weiner
2012-05-21  2:51   ` Zheng Liu
2012-05-21  2:51     ` Zheng Liu
2012-05-21  7:36     ` Johannes Weiner
2012-05-21  7:36       ` Johannes Weiner
2012-05-21  8:59       ` Zheng Liu
2012-05-21  8:59         ` Zheng Liu
2012-05-21  9:37         ` Johannes Weiner
2012-05-21  9:37           ` Johannes Weiner
2012-05-21 11:07           ` Zheng Liu
2012-05-21 11:07             ` Zheng Liu
2012-06-23 11:04             ` Johannes Weiner
2012-06-23 11:04               ` Johannes Weiner
2012-06-23 15:22               ` Rik van Riel
2012-06-23 15:22                 ` Rik van Riel
2012-06-24 23:53               ` Minchan Kim
2012-06-24 23:53                 ` Minchan Kim
2012-06-25  8:08                 ` Johannes Weiner
2012-06-25  8:08                   ` Johannes Weiner
2012-06-25  8:25                   ` Minchan Kim
2012-06-25  8:25                     ` Minchan Kim
2012-06-26 13:51                     ` Johannes Weiner
2012-06-26 13:51                       ` Johannes Weiner
2012-06-26 23:47                       ` Minchan Kim
2012-06-26 23:47                         ` Minchan Kim
2012-05-18  0:40 ` Minchan Kim
2012-05-18  0:40   ` Minchan 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=20120517132324.e9bf9fc8.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mel@csn.ul.ie \
    --cc=mhocko@suse.cz \
    --cc=minchan@kernel.org \
    --cc=riel@redhat.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.