On Fri, 15 Jul 2005, Andi Kleen wrote: > So for what does that batch monstrosity need to know > about the VMAs?
It needs to know where the memory of a process is. Thus /proc/<pid>/numa_maps. > I don't believe any admin will mess with virtual addresses. No but they will mess with vma's which are only identifiable by the starting virtual address. > But for "uncooperative" programs working on bigger objects > like threads/files/shm areas/processes makes much more sense. And gives > much cleaner interfaces too. Look at the existing patches and you see a huge complexity and heuristics because the kernel guesses which vma's to migrate. If the vma are exposed to the batch scheduler / admin then things become much easier to implement and the batch scheduler / admin has finer grained control. > Now I can see some people being interested in more fine grained > policy, but the only sane way to do that is to change the source > code and use libnuma. Can libnuma change the memory policy and move pages of existing processes? > Basically to mess with finegrained virtual addresses you need code access, > and when you have that you can as well do it well and add > libnuma and recompile. libnuma is pretty heavy and AFAIK does not have the functionality that is required here. - 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
