Messages in this thread |  | | Date | Fri, 17 Jul 2009 02:09:30 -0700 (PDT) | From | David Rientjes <> | Subject | Re: [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.
|  |