| 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
| ||
|
Message-Id: <1439190743-13933-1-git-send-email-minchan@kernel.org>
Date: Mon, 10 Aug 2015 16:12:19 +0900
From: Minchan Kim <minchan@...nel.org>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: gioh.kim@....com,
Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
Minchan Kim <minchan@...nel.org>
Subject: [RFC zsmalloc 0/4] meta diet
Recently, Gioh worked to support non-LRU page migration[1].
zRAM is one of customer to use that feature.
For working with that, drivers have to register own address_space
via page->mapping and mark the page->_mapcount as MOBILE page.
Unfortunately, zram have been used those fields to keep own
metadata so there is no room in struct page, which makes hard
to work with the feature.
This patchset try to diet so the goal is to make page->mapping
and page->_mapcount empty.
Trade-off is CPU vs MEMORY so this patchset would make it slow
a bit. I did fio test with perf in my x86 mahchine.
before:
Performance counter stats for './zram_fio.sh' (6 runs):
11186.216003 task-clock (msec) # 1.836 CPUs utilized
1,059 context-switches # 0.098 K/sec
299 cpu-migrations # 0.028 K/sec
159,221 page-faults # 0.015 M/sec
17,629,290,725 cycles # 1.627 GHz (83.56%)
12,375,796,782 stalled-cycles-frontend # 69.95% frontend cycles idle (83.34%)
8,566,377,800 stalled-cycles-backend # 48.42% backend cycles idle (66.91%)
12,828,697,359 instructions # 0.73 insns per cycle
# 0.96 stalled cycles per insn (83.55%)
2,099,817,436 branches # 193.734 M/sec (83.66%)
20,327,794 branch-misses # 0.96% of all branches (83.89%)
6.092967906 seconds time elapsed ( +- 1.49% )
new:
Performance counter stats for './zram_fio.sh' (6 runs):
10574.201402 task-clock (msec) # 1.724 CPUs utilized
1,157 context-switches # 0.107 K/sec
319 cpu-migrations # 0.030 K/sec
159,196 page-faults # 0.015 M/sec
17,825,134,600 cycles # 1.652 GHz (83.61%)
12,462,671,915 stalled-cycles-frontend # 69.98% frontend cycles idle (83.18%)
8,699,972,776 stalled-cycles-backend # 48.85% backend cycles idle (66.81%)
12,958,165,862 instructions # 0.73 insns per cycle
# 0.96 stalled cycles per insn (83.55%)
2,135,158,432 branches # 197.936 M/sec (83.80%)
20,226,663 branch-misses # 0.95% of all branches (83.93%)
6.133316214 seconds time elapsed ( +- 1.80% )
There is a regression under about 1~2% so I think it's reasonable trade-off.
Notice: I marked it as RFC due to two things.
1. I didn't check ./script/checkpatch
2. If Gioh's work is dropped, there is no point to merge this patchset.
If there is no big problem found during review process and Gioh respins
new revision, I will implement migration functions based (this patchset +
Gioh's new).
Thanks.
[1] http://lwn.net/Articles/650917/
Minchan Kim (4):
zsmalloc: keep max_object in size_class
zsmalloc: squeeze inuse into page->mapping
zsmalloc: squeeze freelist into page->mapping
zsmalloc: move struct zs_meta from mapping to somewhere
mm/zsmalloc.c | 346 +++++++++++++++++++++++++++++++++-------------------------
1 file changed, 197 insertions(+), 149 deletions(-)
--
1.9.1
--
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/
Powered by blists - more mailing lists