From: Mel Gorman <mgorman@suse.de>
To: Johannes Weiner <hannes@cmpxchg.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Linux Kernel <linux-kernel@vger.kernel.org>,
Linux-MM <linux-mm@kvack.org>,
Linux-FSDevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH 0/5] Improve sequential read throughput v4r8
Date: Tue, 1 Jul 2014 21:58:17 +0100 [thread overview]
Message-ID: <20140701205817.GY10819@suse.de> (raw)
In-Reply-To: <20140701183915.GW10819@suse.de>
On Tue, Jul 01, 2014 at 07:39:15PM +0100, Mel Gorman wrote:
> The fair zone policy itself is partially working against the lowmem
> reserve idea. The point of the lowmem reserve was to preserve the lower
> zones when an upper zone can be used and the fair zone policy breaks
> that. The fair zone policy ignores that and it was never reconciled. The
> dirty page distribution does a different interleaving again and was never
> reconciled with the fair zone policy or lowmem reserves. kswapd itself was
> not using the classzone_idx it actually woken for although in this case
> it may not matter. The end result is that the model is fairly inconsistent
> which makes comparison against it a difficult exercise at best. About all
> that was left was that from a performance perspective that the fair zone
> allocation policy is not doing the right thing for streaming workloads.
>
The inevitable feedback will be to reconcile those differences so I'm
redid the series and queued it for testing. Patch list currently looks
like
mm: pagemap: Avoid unnecessary overhead when tracepoints are deactivated
mm: Rearrange zone fields into read-only, page alloc, statistics and page reclaim lines
mm: page_alloc: Add ALLOC_DIRTY for dirty page distribution
mm: page_alloc: Only apply the fair zone allocation policy if it's eligible
mm: page_alloc: Only apply either the fair zone or dirty page distribution policy, not both
mm: page_alloc: Reduce cost of the fair zone allocation policy
mm: page_alloc: Reconcile lowmem reserves with fair zone allocation policy
mm: vmscan: Fix oddities with classzone and zone balancing
mm: vmscan: Reconcile balance gap lowmem reclaim with fair zone allocation policy
mm: vmscan: Remove classzone considerations from kswapd decisions
About 13 hours to test for ext3 on the small machine, 3 days for the larger
machine. The test could be accelerated by either reducing the iterations or
the memory size of the machine but that would distort the results too badly.
--
Mel Gorman
SUSE Labs
--
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: Mel Gorman <mgorman@suse.de>
To: Johannes Weiner <hannes@cmpxchg.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Linux Kernel <linux-kernel@vger.kernel.org>,
Linux-MM <linux-mm@kvack.org>,
Linux-FSDevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH 0/5] Improve sequential read throughput v4r8
Date: Tue, 1 Jul 2014 21:58:17 +0100 [thread overview]
Message-ID: <20140701205817.GY10819@suse.de> (raw)
In-Reply-To: <20140701183915.GW10819@suse.de>
On Tue, Jul 01, 2014 at 07:39:15PM +0100, Mel Gorman wrote:
> The fair zone policy itself is partially working against the lowmem
> reserve idea. The point of the lowmem reserve was to preserve the lower
> zones when an upper zone can be used and the fair zone policy breaks
> that. The fair zone policy ignores that and it was never reconciled. The
> dirty page distribution does a different interleaving again and was never
> reconciled with the fair zone policy or lowmem reserves. kswapd itself was
> not using the classzone_idx it actually woken for although in this case
> it may not matter. The end result is that the model is fairly inconsistent
> which makes comparison against it a difficult exercise at best. About all
> that was left was that from a performance perspective that the fair zone
> allocation policy is not doing the right thing for streaming workloads.
>
The inevitable feedback will be to reconcile those differences so I'm
redid the series and queued it for testing. Patch list currently looks
like
mm: pagemap: Avoid unnecessary overhead when tracepoints are deactivated
mm: Rearrange zone fields into read-only, page alloc, statistics and page reclaim lines
mm: page_alloc: Add ALLOC_DIRTY for dirty page distribution
mm: page_alloc: Only apply the fair zone allocation policy if it's eligible
mm: page_alloc: Only apply either the fair zone or dirty page distribution policy, not both
mm: page_alloc: Reduce cost of the fair zone allocation policy
mm: page_alloc: Reconcile lowmem reserves with fair zone allocation policy
mm: vmscan: Fix oddities with classzone and zone balancing
mm: vmscan: Reconcile balance gap lowmem reclaim with fair zone allocation policy
mm: vmscan: Remove classzone considerations from kswapd decisions
About 13 hours to test for ext3 on the small machine, 3 days for the larger
machine. The test could be accelerated by either reducing the iterations or
the memory size of the machine but that would distort the results too badly.
--
Mel Gorman
SUSE Labs
next prev parent reply other threads:[~2014-07-01 20:58 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-30 16:47 [PATCH 0/5] Improve sequential read throughput v4r8 Mel Gorman
2014-06-30 16:47 ` Mel Gorman
2014-06-30 16:48 ` [PATCH 1/4] mm: pagemap: Avoid unnecessary overhead when tracepoints are deactivated Mel Gorman
2014-06-30 16:48 ` Mel Gorman
2014-06-30 16:48 ` [PATCH 2/4] mm: Rearrange zone fields into read-only, page alloc, statistics and page reclaim lines Mel Gorman
2014-06-30 16:48 ` Mel Gorman
2014-06-30 16:48 ` [PATCH 3/4] mm: vmscan: Do not reclaim from lower zones if they are balanced Mel Gorman
2014-06-30 16:48 ` Mel Gorman
2014-06-30 16:48 ` [PATCH 4/4] mm: page_alloc: Reduce cost of the fair zone allocation policy Mel Gorman
2014-06-30 16:48 ` Mel Gorman
2014-06-30 21:14 ` Andrew Morton
2014-06-30 21:14 ` Andrew Morton
2014-06-30 21:51 ` Mel Gorman
2014-06-30 21:51 ` Mel Gorman
2014-06-30 22:09 ` Andrew Morton
2014-06-30 22:09 ` Andrew Morton
2014-07-01 8:02 ` Mel Gorman
2014-07-01 8:02 ` Mel Gorman
2014-07-01 17:16 ` [PATCH 0/5] Improve sequential read throughput v4r8 Johannes Weiner
2014-07-01 17:16 ` Johannes Weiner
2014-07-01 18:39 ` Mel Gorman
2014-07-01 18:39 ` Mel Gorman
2014-07-01 20:58 ` Mel Gorman [this message]
2014-07-01 20:58 ` Mel Gorman
2014-07-01 21:25 ` Johannes Weiner
2014-07-01 21:25 ` Johannes Weiner
2014-07-02 15:44 ` Johannes Weiner
2014-07-02 15:44 ` Johannes Weiner
2014-07-02 15:53 ` Mel Gorman
2014-07-02 15:53 ` Mel Gorman
2014-07-01 22:38 ` Dave Chinner
2014-07-01 22:38 ` Dave Chinner
2014-07-01 23:09 ` Mel Gorman
2014-07-01 23:09 ` Mel Gorman
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=20140701205817.GY10819@suse.de \
--to=mgorman@suse.de \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
/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.