[lkml]   [2009]   [Jul]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
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 should be initialized

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