linux-kernel - Re: [RFC PATCH 00/12] mm: mirrored memory support for page buddy allocations

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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 16 Jun 2015 09:53:28 +0200
From:	Vlastimil Babka <vbabka@...e.cz>
To:	Xishi Qiu <qiuxishi@...wei.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	nao.horiguchi@...il.com, Yinghai Lu <yinghai@...nel.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>, mingo@...e.hu,
	Xiexiuqi <xiexiuqi@...wei.com>,
	Hanjun Guo <guohanjun@...wei.com>,
	"Luck, Tony" <tony.luck@...el.com>
CC:	Linux MM <linux-mm@...ck.org>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 00/12] mm: mirrored memory support for page buddy
 allocations

On 06/04/2015 02:54 PM, Xishi Qiu wrote:
> Intel Xeon processor E7 v3 product family-based platforms introduces support
> for partial memory mirroring called as 'Address Range Mirroring'. This feature
> allows BIOS to specify a subset of total available memory to be mirrored (and
> optionally also specify whether to mirror the range 0-4 GB). This capability
> allows user to make an appropriate tradeoff between non-mirrored memory range
> and mirrored memory range thus optimizing total available memory and still
> achieving highly reliable memory range for mission critical workloads and/or
> kernel space.
> 
> Tony has already send a patchset to supprot this feature at boot time.
> https://lkml.org/lkml/2015/5/8/521
> 
> This patchset can support the feature after boot time. It introduces mirror_info
> to save the mirrored memory range. Then use __GFP_MIRROR to allocate mirrored 
> pages. 
> 
> I think add a new migratetype is btter and easier than a new zone, so I use

If the mirrored memory is in a single reasonably compact (no large holes) range
(per NUMA node) and won't dynamically change its size, then zone might be a
better option. For one thing, it will still allow distinguishing movable and
unmovable allocations within the mirrored memory.

We had enough fun with MIGRATE_CMA and all kinds of checks it added to allocator
hot paths, and even CMA is now considering moving to a separate zone.

> MIGRATE_MIRROR to manage the mirrored pages. However it changed some code in the
> core file, please review and comment, thanks.
> 
> TBD: 
> 1) call add_mirror_info() to fill mirrored memory info.
> 2) add compatibility with memory online/offline.
> 3) add more interface? others?
> 
> Xishi Qiu (12):
>   mm: add a new config to manage the code
>   mm: introduce mirror_info
>   mm: introduce MIGRATE_MIRROR to manage the mirrored pages
>   mm: add mirrored pages to buddy system
>   mm: introduce a new zone_stat_item NR_FREE_MIRROR_PAGES
>   mm: add free mirrored pages info
>   mm: introduce __GFP_MIRROR to allocate mirrored pages
>   mm: use mirrorable to switch allocate mirrored memory
>   mm: enable allocate mirrored memory at boot time
>   mm: add the buddy system interface
>   mm: add the PCP interface
>   mm: let slab/slub/slob use mirrored memory
> 
>  arch/x86/mm/numa.c     |   3 ++
>  drivers/base/node.c    |  17 ++++---
>  fs/proc/meminfo.c      |   6 +++
>  include/linux/gfp.h    |   5 +-
>  include/linux/mmzone.h |  23 +++++++++
>  include/linux/vmstat.h |   2 +
>  kernel/sysctl.c        |   9 ++++
>  mm/Kconfig             |   8 +++
>  mm/page_alloc.c        | 134 ++++++++++++++++++++++++++++++++++++++++++++++---
>  mm/slab.c              |   3 +-
>  mm/slob.c              |   2 +-
>  mm/slub.c              |   2 +-
>  mm/vmstat.c            |   4 ++
>  13 files changed, 202 insertions(+), 16 deletions(-)
> 

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