Messages in this thread | | | Date | Sun, 20 Feb 2005 22:49:23 +0100 | From | Andi Kleen <> | Subject | Re: [RFC 2.6.11-rc2-mm2 0/7] mm: manual page migration -- overview II |
| |
> >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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |