From: Mel Gorman <mgorman@suse.de>
To: Linux-MM <linux-mm@kvack.org>,
Linux-FSDevel <linux-fsdevel@vger.kernel.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
Vlastimil Babka <vbabka@suse.cz>, Jan Kara <jack@suse.cz>,
Michal Hocko <mhocko@suse.cz>, Hugh Dickins <hughd@google.com>,
Mel Gorman <mgorman@suse.de>,
Linux Kernel <linux-kernel@vger.kernel.org>
Subject: [PATCH 00/17] Misc page alloc, shmem, mark_page_accessed and page_waitqueue optimisations
Date: Thu, 1 May 2014 09:44:31 +0100 [thread overview]
Message-ID: <1398933888-4940-1-git-send-email-mgorman@suse.de> (raw)
I was investigating a performance bug that looked like dd to tmpfs
had regressed. The bulk of the problem turned out to be a difference
in Kconfig but it got me looking at the unnecessary overhead in tmpfs,
mark_page_accessed and parts of the allocator. This series is the result.
The patches themselves have details of the performance results but here
are some of the results based on ext4. This is the result of dd'ing to
a file multiple times on tmpfs
loopdd Throughput
3.15.0-rc3 3.15.0-rc3
vanilla lockpage-v2r33
Min 4096.0000 ( 0.00%) 3891.2000 ( -5.00%)
Mean 4840.1067 ( 0.00%) 5154.1333 ( 6.49%)
TrimMean 4867.6571 ( 0.00%) 5204.1143 ( 6.91%)
Stddev 160.6807 ( 0.00%) 275.1917 ( 71.27%)
Max 5017.6000 ( 0.00%) 5324.8000 ( 6.12%)
loopdd elapsed time
3.15.0-rc3 3.15.0-rc3
vanilla lockpage-v2r33
Min elapsed 0.4100 ( 0.00%) 0.3900 ( 4.88%)
Mean elapsed 0.4780 ( 0.00%) 0.4203 ( 12.06%)
TrimMean elapsed 0.4796 ( 0.00%) 0.4179 ( 12.88%)
Stddev elapsed 0.0353 ( 0.00%) 0.0379 ( -7.23%)
Max elapsed 0.5100 ( 0.00%) 0.4800 ( 5.88%)
This table shows the latency in usecs of accessing ext4-backed
mappings of various sizes
lat_mmap
3.15.0-rc3 3.15.0-rc3
vanilla lockpage-v2r33
Procs 107M 557.0000 ( 0.00%) 544.0000 ( 2.33%)
Procs 214M 1150.0000 ( 0.00%) 1058.0000 ( 8.00%)
Procs 322M 1897.0000 ( 0.00%) 1554.0000 ( 18.08%)
Procs 429M 2188.0000 ( 0.00%) 2652.0000 (-21.21%)
Procs 536M 2622.0000 ( 0.00%) 2473.0000 ( 5.68%)
Procs 644M 3065.0000 ( 0.00%) 2486.0000 ( 18.89%)
Procs 751M 3400.0000 ( 0.00%) 3012.0000 ( 11.41%)
Procs 859M 3996.0000 ( 0.00%) 3926.0000 ( 1.75%)
Procs 966M 4646.0000 ( 0.00%) 3763.0000 ( 19.01%)
Procs 1073M 4981.0000 ( 0.00%) 4154.0000 ( 16.60%)
Procs 1181M 5419.0000 ( 0.00%) 5152.0000 ( 4.93%)
Procs 1288M 5553.0000 ( 0.00%) 5538.0000 ( 0.27%)
Procs 1395M 5841.0000 ( 0.00%) 5730.0000 ( 1.90%)
Procs 1503M 6225.0000 ( 0.00%) 5981.0000 ( 3.92%)
Procs 1610M 6558.0000 ( 0.00%) 6332.0000 ( 3.45%)
Procs 1717M 7130.0000 ( 0.00%) 6741.0000 ( 5.46%)
Procs 1825M 9394.0000 ( 0.00%) 8483.0000 ( 9.70%)
Procs 1932M 8056.0000 ( 0.00%) 9427.0000 (-17.02%)
Procs 2040M 8463.0000 ( 0.00%) 9030.0000 ( -6.70%)
Procs 2147M 9014.0000 ( 0.00%) 8608.0000 ( 4.50%)
In general the system CPU overhead is lower.
arch/tile/mm/homecache.c | 2 +-
fs/btrfs/extent_io.c | 11 +-
fs/btrfs/file.c | 5 +-
fs/buffer.c | 7 +-
fs/ext4/mballoc.c | 14 +-
fs/f2fs/checkpoint.c | 3 -
fs/f2fs/node.c | 2 -
fs/fuse/dev.c | 2 +-
fs/fuse/file.c | 2 -
fs/gfs2/aops.c | 1 -
fs/gfs2/meta_io.c | 4 +-
fs/ntfs/attrib.c | 1 -
fs/ntfs/file.c | 1 -
include/linux/cpuset.h | 31 +++++
include/linux/gfp.h | 4 +-
include/linux/mmzone.h | 22 ++-
include/linux/page-flags.h | 18 +++
include/linux/pageblock-flags.h | 34 ++++-
include/linux/pagemap.h | 115 ++++++++++++++--
include/linux/swap.h | 9 +-
kernel/cpuset.c | 8 +-
kernel/sched/wait.c | 3 +-
mm/filemap.c | 292 ++++++++++++++++++++++------------------
mm/page_alloc.c | 226 ++++++++++++++++++-------------
mm/shmem.c | 8 +-
mm/swap.c | 17 ++-
mm/swap_state.c | 2 +-
mm/vmscan.c | 6 +-
28 files changed, 556 insertions(+), 294 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>
next reply other threads:[~2014-05-01 8:44 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-01 8:44 Mel Gorman [this message]
2014-05-01 8:44 ` [PATCH 01/17] mm: page_alloc: Do not update zlc unless the zlc is active Mel Gorman
2014-05-01 13:25 ` Johannes Weiner
2014-05-06 15:04 ` Rik van Riel
2014-05-01 8:44 ` [PATCH 02/17] mm: page_alloc: Do not treat a zone that cannot be used for dirty pages as "full" Mel Gorman
2014-05-06 15:09 ` Rik van Riel
2014-05-01 8:44 ` [PATCH 03/17] mm: page_alloc: Use jump labels to avoid checking number_of_cpusets Mel Gorman
2014-05-06 15:10 ` Rik van Riel
2014-05-06 20:23 ` Peter Zijlstra
2014-05-06 22:21 ` Mel Gorman
2014-05-07 9:04 ` Peter Zijlstra
2014-05-07 9:43 ` Mel Gorman
2014-05-01 8:44 ` [PATCH 04/17] mm: page_alloc: Calculate classzone_idx once from the zonelist ref Mel Gorman
2014-05-06 16:01 ` Rik van Riel
2014-05-01 8:44 ` [PATCH 05/17] mm: page_alloc: Only check the zone id check if pages are buddies Mel Gorman
2014-05-06 16:48 ` Rik van Riel
2014-05-01 8:44 ` [PATCH 06/17] mm: page_alloc: Only check the alloc flags and gfp_mask for dirty once Mel Gorman
2014-05-06 17:24 ` Rik van Riel
2014-05-01 8:44 ` [PATCH 07/17] mm: page_alloc: Take the ALLOC_NO_WATERMARK check out of the fast path Mel Gorman
2014-05-06 17:25 ` Rik van Riel
2014-05-01 8:44 ` [PATCH 08/17] mm: page_alloc: Use word-based accesses for get/set pageblock bitmaps Mel Gorman
2014-05-02 22:34 ` Sasha Levin
2014-05-04 13:14 ` Mel Gorman
2014-05-05 12:40 ` Vlastimil Babka
2014-05-06 9:13 ` Mel Gorman
2014-05-06 14:42 ` Vlastimil Babka
2014-05-06 15:12 ` Mel Gorman
2014-05-06 20:34 ` Peter Zijlstra
2014-05-06 22:24 ` Mel Gorman
2014-05-01 8:44 ` [PATCH 09/17] mm: page_alloc: Reduce number of times page_to_pfn is called Mel Gorman
2014-05-06 18:47 ` Rik van Riel
2014-05-01 8:44 ` [PATCH 10/17] mm: page_alloc: Lookup pageblock migratetype with IRQs enabled during free Mel Gorman
2014-05-06 18:48 ` Rik van Riel
2014-05-01 8:44 ` [PATCH 11/17] mm: page_alloc: Use unsigned int for order in more places Mel Gorman
2014-05-01 14:35 ` Dave Hansen
2014-05-01 15:11 ` Mel Gorman
2014-05-01 15:38 ` Dave Hansen
2014-05-06 18:49 ` Rik van Riel
2014-05-01 8:44 ` [PATCH 12/17] mm: page_alloc: Convert hot/cold parameter and immediate callers to bool Mel Gorman
2014-05-06 18:49 ` Rik van Riel
2014-05-01 8:44 ` [PATCH 13/17] mm: shmem: Avoid atomic operation during shmem_getpage_gfp Mel Gorman
2014-05-06 18:53 ` Rik van Riel
2014-05-01 8:44 ` [PATCH 14/17] mm: Do not use atomic operations when releasing pages Mel Gorman
2014-05-01 13:29 ` Johannes Weiner
2014-05-01 13:39 ` Mel Gorman
2014-05-01 13:47 ` Johannes Weiner
2014-05-06 18:54 ` Rik van Riel
2014-05-01 8:44 ` [PATCH 15/17] mm: Do not use unnecessary atomic operations when adding pages to the LRU Mel Gorman
2014-05-01 13:33 ` Johannes Weiner
2014-05-01 13:40 ` Mel Gorman
2014-05-06 15:30 ` Vlastimil Babka
2014-05-06 15:55 ` Mel Gorman
2014-05-01 8:44 ` [PATCH 16/17] mm: Non-atomically mark page accessed during page cache allocation where possible Mel Gorman
2014-05-01 8:44 ` [PATCH 17/17] mm: filemap: Avoid unnecessary barries and waitqueue lookup in unlock_page fastpath Mel Gorman
2014-05-05 10:50 ` Jan Kara
2014-05-07 9:03 ` Mel Gorman
2014-05-06 20:30 ` Peter Zijlstra
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=1398933888-4940-1-git-send-email-mgorman@suse.de \
--to=mgorman@suse.de \
--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=mhocko@suse.cz \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).