Messages in this thread | | | Date | 15 Feb 2005 13:14:04 +0100 | Date | Tue, 15 Feb 2005 13:14:04 +0100 | From | Andi Kleen <> | Subject | Re: [RFC 2.6.11-rc2-mm2 0/7] mm: manual page migration -- overview II |
| |
[Sorry, didn't answer to everything in your mail the first time. See previous mail for beginning]
On Mon, Feb 14, 2005 at 06:29:45PM -0600, Ray Bryant wrote: > migrating, and figure out from that what portions of which pid's > address spaces need to migrated so that we satisfy the constraints > given above. I admit that this may be viewed as ugly, but I really > can't figure out a better solution than this without shuffling a > ton of ugly code into the kernel.
I like the concept of marking stuff that shouldn't be migrated externally (using NUMA policy) better.
> > One issue that hasn't been addressed is the following: given a > particular entry in /proc/pid/maps, how does one figure out whether > that entry is mapped into some other process in the system, one > that is not in the set of processes to be migrated? One could
[...]
Marking things externally would take care of that.
> If we did this, we still have to have the page migration system call > to handle those cases for the tmpfs/hugetlbfs/sysv shm segments whose > pages were placed by first touch and for which there used to not be > a memory policy. As discussed in a previous note, we are not in a
You can handle those with mbind(..., MPOL_F_STRICT); (once it is hooked up to page migration)
Just mmap the tmpfs/shm/hugetlb file in an external program and apply the policy. That is what numactl supports today too for shm files like this.
It should work later.
-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/
| |