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: <alpine.DEB.2.00.1211011431130.19373@chino.kir.corp.google.com>
Date:	Thu, 1 Nov 2012 14:36:14 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	Wen Congyang <wency@...fujitsu.com>
cc:	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	linux-doc@...r.kernel.org, Rob Landley <rob@...dley.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Yasuaki Ishimatsu <isimatu.yasuaki@...fujitsu.com>,
	Lai Jiangshan <laijs@...fujitsu.com>,
	Jiang Liu <jiang.liu@...wei.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Minchan Kim <minchan.kim@...il.com>,
	Mel Gorman <mgorman@...e.de>, Yinghai Lu <yinghai@...nel.org>,
	"rusty@...tcorp.com.au" <rusty@...tcorp.com.au>
Subject: Re: [PART3 Patch 00/14] introduce N_MEMORY

On Thu, 1 Nov 2012, Wen Congyang wrote:

> > This doesn't describe why we need the new node state, unfortunately.  It 
> 
> 1. Somethimes, we use the node which contains the memory that can be used by
>    kernel.
> 2. Sometimes, we use the node which contains the memory.
> 
> In case1, we use N_HIGH_MEMORY, and we use N_MEMORY in case2.
> 

Yeah, that's clear, but the question is still _why_ we want two different 
nodemasks.  I know that this part of the patchset simply introduces the 
new nodemask because the name "N_MEMORY" is more clear than 
"N_HIGH_MEMORY", but there's no real incentive for making that change by 
introducing a new nodemask where a simple rename would suffice.

I can only assume that you want to later use one of them for a different 
purpose: those that do not include nodes that consist of only 
ZONE_MOVABLE.  But that change for MPOL_BIND is nacked since it 
significantly changes the semantics of set_mempolicy() and you can't break 
userspace (see my response to that from yesterday).  Until that problem is 
addressed, then there's no reason for the additional nodemask so nack on 
this series as well.
--
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