linux-kernel - [RFC PATCH 0/5] Support multiple pages allocation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <1372840460-5571-1-git-send-email-iamjoonsoo.kim@lge.com>
Date:	Wed,  3 Jul 2013 17:34:15 +0900
From:	Joonsoo Kim <iamjoonsoo.kim@....com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Mel Gorman <mgorman@...e.de>, David Rientjes <rientjes@...gle.com>,
	Glauber Costa <glommer@...il.com>,
	Johannes Weiner <hannes@...xchg.org>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Rik van Riel <riel@...hat.com>,
	Hugh Dickins <hughd@...gle.com>,
	Minchan Kim <minchan@...nel.org>,
	Jiang Liu <jiang.liu@...wei.com>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, Joonsoo Kim <js1304@...il.com>,
	Joonsoo Kim <iamjoonsoo.kim@....com>
Subject: [RFC PATCH 0/5] Support multiple pages allocation

Hello.

This patchset introduces multiple pages allocation feature to buddy
allocator. Currently, there is no ability to allocate multiple pages
at once, so we should invoke single page allocation logic repeatedly.
This has some overheads like as overhead of function call with many
arguments and overhead for finding proper node and zone.

With this patchset, we can reduce these overheads.
Here goes some experimental result of allocation test.
I did the test on below setup.
CPU: 4 cpus, 3.00GHz.
RAM: 4 GB
Kernel: v3.10 vanilla

Each case of result is an average of 20 runs.

Time(us) : Improvement Percentage

Before			Patched	1 page		Patched	2 page		Patched	4 page
--------------------------------------------------------------------------------------
128KB	5.3	0	4.45	16.04%		3.25	38.68%		3.75	29.25%
256KB	13.15	0	10.15	22.81%		8.8	33.08%		8.5	35.36%
512KB	72.3	0	34.65	52.07%		82.65	-14.32%		25	65.42%
1024KB	114.9	0	112.95	1.70%		87.55	23.80%		64.7	43.69%
2MB	131.65	0	102.35	22.26%		91.95	30.16%		126.05	4.25%
4MB	225.55	0	213.2	5.48%		181.95	19.33%		200.8	10.97%
8MB	408.6	0	442.85	-8.38%		350.4	14.24%		365.15	10.63%
16MB	730.55	0	683.35	6.46%		735.5	-0.68%		698.3	4.41%
32MB	1682.6	0	1665.85	1.00%		1445.1	14.12%		1157.05	31.23%
64MB	3229.4	0	3463.2	-7.24%		2538.4	21.40%		1850.55	42.70%
128MB	5465.6	0	4816.2	11.88%		4448.3	18.61%		3528.25	35.45%
256MB	9526.9	0	10091.75 -5.93%		8514.5	10.63%		7978.2	16.26%
512MB	19029.05 0	20079.7	-5.52%		17059.05 10.35%		14713.65 22.68%
1024MB	37284.9	0	39453.75 -5.82%		32969.7	11.57%		28161.65 24.47%



Before			Patched	8 page		Patched	16 page		Patched	32 page
---------------------------------------------------------------------------------------
128KB	5.3	0	3.05	42.45%		2.65	50.00%		2.85	46.23%
256KB	13.15	0	8.2	37.64%		7.45	43.35%		7.95	39.54%
512KB	72.3	0	16.8	76.76%		17.7	75.52%		14.55	79.88%
1024KB	114.9	0	60.05	47.74%		93.65	18.49%		74.2	35.42%
2MB	131.65	0	119.8	9.00%		72.6	44.85%		84.7	35.66%
4MB	225.55	0	227.3	-0.78%		149.95	33.52%		153.6	31.90%
8MB	408.6	0	372.5	8.84%		304.95	25.37%		340.55	16.65%
16MB	730.55	0	772.2	-5.70%		567.4	22.33%		618.3	15.37%
32MB	1682.6	0	1217.7	27.63%		1098.25	34.73%		1168.7	30.54%
64MB	3229.4	0	2237.75	30.71%		1817.8	43.71%		1998.25	38.12%
128MB	5465.6	0	3504.25	35.89%		3466.75	36.57%		3159.35	42.20%
256MB	9526.9	0	7071.2	25.78%		7095.05	25.53%		6800.9	28.61%
512MB	19029.05 0	13640.85 28.32%		13098.2	31.17%		12778.1	32.85%
1024MB	37284.9	0	25897.15 30.54%		24875.6	33.28%		24179.3	35.15%



For one page allocation at once, this patchset makes allocator slower than
before (-5%). But, for more page allocation at once, this patchset makes
allocator faster than before greately.

At first, we can apply this feature to page cache readahead logic which
allocate single page repeatedly. I attach sample implementation to this
patchset(Patch 2-5).

Current implementation is not yet complete. Before polishing this feature,
I want to hear expert's opinion. I don't have any trouble with
current allocator, however, I think that we need this feature soon,
because device I/O is getting faster rapidly and allocator should
catch up this speed.

Thanks.

Joonsoo Kim (5):
  mm, page_alloc: support multiple pages allocation
  mm, page_alloc: introduce alloc_pages_exact_node_multiple()
  radix-tree: introduce radix_tree_[next/prev]_present()
  readahead: remove end range check
  readhead: support multiple pages allocation for readahead

 include/linux/gfp.h        |   16 ++++++++++--
 include/linux/pagemap.h    |   19 +++++++++-----
 include/linux/radix-tree.h |    4 +++
 lib/radix-tree.c           |   34 ++++++++++++++++++++++++
 mm/filemap.c               |   18 ++++++++-----
 mm/mempolicy.c             |    6 +++--
 mm/page_alloc.c            |   62 +++++++++++++++++++++++++++++++++++---------
 mm/readahead.c             |   46 ++++++++++++++++++++++----------
 8 files changed, 162 insertions(+), 43 deletions(-)

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/