Re: [BUG] set_mempolicy(MPOL_INTERLEAV) cause kernel panic

[David Rientjes <rientjes@google.com>]

On Fri, 17 Jul 2009, KAMEZAWA Hiroyuki wrote:

> IMHO, the application itseld should be notifed to change its mempolicy by
> hot-plug script on the host. While an application uses interleave, a new node
> hot-added is just a noise. I think "How pages are interleaved" should not be
> changed implicitly. Then, checking at set_mempolicy() seems sane. If notified,
> application can do page migration and rebuild his mapping in ideal way.
> 

Agreed, it doesn't seem helpful to add a node to MPOL_INTERLEAVE for 
memory hotplug; the same is probably true of MPOL_BIND as well since the 
application will never want to unknowingly expand its set of allowed 
nodes.  There's no case where MPOL_PREFERRED would want to implicitly 
switch to the added node.

I'm not convinced that we have to support hot-add in existing mempolicies 
at all.

> BUT I don't linke init->mem_allowed contains N_POSSIBLE...it should be initialized
> to N_HIGH_MEMORY, IMHO.
> 

It doesn't matter for the page allocator since zonelists will never 
include zones from nodes that aren't online, so the underlying bug here 
does seem to be the behavior of ->mems_allowed and we're probably only 
triggering it by mempolicies.  cpuset_track_online_nodes() should be 
keeping top_cpuset's mems_allowed consistent with N_HIGH_MEMORY and all 
descendents must have a subset of top_cpuset's nodes, though.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>