lkml.org 
[lkml]   [2009]   [Jul]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [BUG] set_mempolicy(MPOL_INTERLEAV) cause kernel panic
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.


\
 
 \ /
  Last update: 2009-07-17 11:11    [W:0.065 / U:44.080 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site