All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Mel Gorman <mgorman@suse.de>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>,
	Linux-MM <linux-mm@kvack.org>,
	Linux-FSDevel <linux-fsdevel@vger.kernel.org>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Jens Axboe <axboe@kernel.dk>, Jeff Moyer <jmoyer@redhat.com>,
	Dave Chinner <david@fromorbit.com>
Subject: Re: [PATCH 3/6] mm: vmscan: Do not reclaim from lower zones if they are balanced
Date: Wed, 25 Jun 2014 16:32:50 -0700	[thread overview]
Message-ID: <20140625163250.354f12cd0fa5ff16e32056bf@linux-foundation.org> (raw)
In-Reply-To: <1403683129-10814-4-git-send-email-mgorman@suse.de>

On Wed, 25 Jun 2014 08:58:46 +0100 Mel Gorman <mgorman@suse.de> wrote:

> Historically kswapd scanned from DMA->Movable in the opposite direction
> to the page allocator to avoid allocating behind kswapd direction of
> progress. The fair zone allocation policy altered this in a non-obvious
> manner.
> 
> Traditionally, the page allocator prefers to use the highest eligible zone
> until the watermark is depleted, woke kswapd and moved onto the next zone.
> kswapd scans zones in the opposite direction so the scanning lists on
> 64-bit look like this;
> 
> ...
>
> Note that this patch makes a large performance difference for lower
> numbers of threads and brings performance closer to 3.0 figures. It was
> also tested against xfs and there are similar gains although I don't have
> 3.0 figures to compare against. There are still regressions for higher
> number of threads but this is related to changes in the CFQ IO scheduler.
> 

Why did this patch make a difference to sequential read performance? 
IOW, by what means was/is reclaim interfering with sequential reads?


WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: Mel Gorman <mgorman@suse.de>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>,
	Linux-MM <linux-mm@kvack.org>,
	Linux-FSDevel <linux-fsdevel@vger.kernel.org>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Jens Axboe <axboe@kernel.dk>, Jeff Moyer <jmoyer@redhat.com>,
	Dave Chinner <david@fromorbit.com>
Subject: Re: [PATCH 3/6] mm: vmscan: Do not reclaim from lower zones if they are balanced
Date: Wed, 25 Jun 2014 16:32:50 -0700	[thread overview]
Message-ID: <20140625163250.354f12cd0fa5ff16e32056bf@linux-foundation.org> (raw)
In-Reply-To: <1403683129-10814-4-git-send-email-mgorman@suse.de>

On Wed, 25 Jun 2014 08:58:46 +0100 Mel Gorman <mgorman@suse.de> wrote:

> Historically kswapd scanned from DMA->Movable in the opposite direction
> to the page allocator to avoid allocating behind kswapd direction of
> progress. The fair zone allocation policy altered this in a non-obvious
> manner.
> 
> Traditionally, the page allocator prefers to use the highest eligible zone
> until the watermark is depleted, woke kswapd and moved onto the next zone.
> kswapd scans zones in the opposite direction so the scanning lists on
> 64-bit look like this;
> 
> ...
>
> Note that this patch makes a large performance difference for lower
> numbers of threads and brings performance closer to 3.0 figures. It was
> also tested against xfs and there are similar gains although I don't have
> 3.0 figures to compare against. There are still regressions for higher
> number of threads but this is related to changes in the CFQ IO scheduler.
> 

Why did this patch make a difference to sequential read performance? 
IOW, by what means was/is reclaim interfering with sequential reads?

--
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>

  reply	other threads:[~2014-06-25 23:32 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-25  7:58 [PATCH 0/6] Improve sequential read throughput v2 Mel Gorman
2014-06-25  7:58 ` Mel Gorman
2014-06-25  7:58 ` [PATCH 1/6] mm: pagemap: Avoid unnecessary overhead when tracepoints are deactivated Mel Gorman
2014-06-25  7:58   ` Mel Gorman
2014-06-25  7:58 ` [PATCH 2/6] mm: Rearrange zone fields into read-only, page alloc, statistics and page reclaim lines Mel Gorman
2014-06-25  7:58   ` Mel Gorman
2014-06-25  7:58 ` [PATCH 3/6] mm: vmscan: Do not reclaim from lower zones if they are balanced Mel Gorman
2014-06-25  7:58   ` Mel Gorman
2014-06-25 23:32   ` Andrew Morton [this message]
2014-06-25 23:32     ` Andrew Morton
2014-06-26 10:17     ` Mel Gorman
2014-06-26 10:17       ` Mel Gorman
2014-06-25  7:58 ` [PATCH 4/6] mm: page_alloc: Reduce cost of the fair zone allocation policy Mel Gorman
2014-06-25  7:58   ` Mel Gorman
2014-06-25  7:58 ` [PATCH 5/6] mm: page_alloc: Reduce cost of dirty zone balancing Mel Gorman
2014-06-25  7:58   ` Mel Gorman
2014-06-25 23:35   ` Andrew Morton
2014-06-25 23:35     ` Andrew Morton
2014-06-26  8:43     ` Mel Gorman
2014-06-26  8:43       ` Mel Gorman
2014-06-26 14:37       ` Johannes Weiner
2014-06-26 14:56         ` Mel Gorman
2014-06-26 14:56           ` Mel Gorman
2014-06-26 15:11           ` Johannes Weiner
2014-06-26 15:11             ` Johannes Weiner
2014-06-25  7:58 ` [PATCH 6/6] cfq: Increase default value of target_latency Mel Gorman
2014-06-25  7:58   ` Mel Gorman
2014-06-26 15:36   ` Jeff Moyer
2014-06-26 15:36     ` Jeff Moyer
2014-06-26 16:19     ` Mel Gorman
2014-06-26 16:19       ` Mel Gorman
2014-06-26 16:50       ` Jeff Moyer
2014-06-26 16:50         ` Jeff Moyer
2014-06-26 17:45         ` Mel Gorman
2014-06-26 17:45           ` Mel Gorman
2014-06-26 18:04           ` Jeff Moyer
2014-06-26 18:04             ` Jeff Moyer

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=20140625163250.354f12cd0fa5ff16e32056bf@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=axboe@kernel.dk \
    --cc=david@fromorbit.com \
    --cc=hannes@cmpxchg.org \
    --cc=jmoyer@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    /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.