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]
Message-ID: <20150615172023.GA12088@agluck-desk.sc.intel.com>
Date:	Mon, 15 Jun 2015 10:20:25 -0700
From:	"Luck, Tony" <tony.luck@...el.com>
To:	Kamezawa Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
Cc:	Xishi Qiu <qiuxishi@...wei.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"nao.horiguchi@...il.com" <nao.horiguchi@...il.com>,
	Yinghai Lu <yinghai@...nel.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	"mingo@...e.hu" <mingo@...e.hu>, Xiexiuqi <xiexiuqi@...wei.com>,
	Hanjun Guo <guohanjun@...wei.com>,
	Linux MM <linux-mm@...ck.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 10/12] mm: add the buddy system interface

On Mon, Jun 15, 2015 at 05:47:27PM +0900, Kamezawa Hiroyuki wrote:
> So, there are 3 ideas.
> 
>  (1) kernel only from MIRROR / user only from MOVABLE (Tony)
>  (2) kernel only from MIRROR / user from MOVABLE + MIRROR(ASAP)  (AKPM suggested)
>      This makes use of the fact MOVABLE memory is reclaimable but Tony pointed out
>      the memory reclaim can be critical for GFP_ATOMIC.
>  (3) kernel only from MIRROR / user from MOVABLE, special user from MIRROR (Xishi)
> 
> 2 Implementation ideas.
>   - creating ZONE
>   - creating new alloation attribute
> 
> I don't convince whether we need some new structure in mm. Isn't it good to use
> ZONE_MOVABLE for not-mirrored memory ?
> Then, disable fallback from ZONE_MOVABLE -> ZONE_NORMAL for (1) and (3)

We might need to rename it ... right now the memory hotplug
people use ZONE_MOVABLE to indicate regions of physical memory
that can be removed from the system.  I'm wondering whether
people will want systems that have both removable and mirrored
areas?  Then we have four attribute combinations:

mirror=no  removable=no  - prefer to use for user, could use for kernel if we run out of mirror
mirror=no  removable=yes - can only be used for user (kernel allocation makes it not-removable)
mirror=yes removable=no  - use for kernel, possibly for special users if we define some interface
mirror=yes removable=yes - must not use for kernel ... would have to give to user ... seems like a bad idea to configure a system this way

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ