> One always needs control over what is migrated. Ideally one would be able > to specify that only the vma containing the huge amount of sparsely > accessed data is to be migrated if memory becomes tight but the process > continues to run on the same node. The stack and text segments and > libraries should stay on the node.
There is no way to do sane locking from user space for such external manipulation of arbitary mappings. You need to do it in the kernel. BTW all your talking about VMAs is useless here anyways because NUMA policies don't necessarily match VMAs and neither does allocated memory. > Are you willing to allow us to control memory placement? Or will it be > automatically? If automatically then maybe you need to get rid of libnuma > and numactl and put it all in the scheduler. Otherwise please full control > and not some half-way measures. Without my NUMA policy code you wouldn't have any usable NUMA policy today, But my goal is definitely to keep the kernel interfaces for this clean. And what you're proposing is *not* clean. I think the per VMA approach is fundamentally wrong because virtual addresses are nothing an external user can safely access. Doing it on higher level objects allows better interfaces and better locking, and as far as I can see process/shm segment/file are the only useful objects for this. It should basically work like swapping without the need to SIGSTOP the target. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
