> >Perhaps node masks would be better and teaching the kernel to handle > >relative distances inside the masks transparently while migrating? > >Not sure how complicated this would be to implement though. > > > >Supporting interleaving on the new nodes may be also useful, that would > >need a policy argument at least too and masks. > > > > The worry I have about using node masks is that it is not as general as > old_node,new_node mappings (or preferably, the original proposal I made > of old_node_list, new_node_list). One can't differentiate between the
I agree that the node arrays are better for this case. > >>and the majority of the memory is shared, then we only need to make > >>one system call and one page table scan. (We just "migrate" the > >>shared object once.) So the time to do the page table scans disappears > > > > > >I don't like this because it makes it much more complicated > >to use for user space. And you can set separate policies for > >shared objects anyways. > > Yes, but only programs that care have to use the va_start and > va_end. Programs who want to move everything can specify > 0 and MAX_INT there and they are done. I still think it's fundamentally unclean and racy. External processes shouldn't mess with virtual addresses of other processes. > >-Andi > > But we are least at the level of agreeing that the new system > call looks something like the following: > > migrate_pages(pid, count, old_list, new_list); > > right? For the external case probably yes. For internal (process does this on its own address space) it should be hooked into mbind() too. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/