On Tue, Jun 01, 2010 at 05:48:10PM +0200, Andi Kleen wrote: > Nick Piggin <npiggin@xxxxxxx> writes: > > > This isn't really a new problem, and I don't know how important it is, > > but I recently came across it again when doing some aim7 testing with > > huge numbers of tasks. > > Seems reasonable. Of course you need to at least > save/restore the old CPU policy, and use a subset of it. The mpolicy? My patch does that (mpol_prefer_cpu_start/end). The real problem is that it can actually violate the parent's mempolicy. For example MPOL_BIND and cpus_allowed set on a node outside the mempolicy. What is needed is to execute with the existing mempolicy, but from the point of view of the destination CPU. A bit more work on the mpol code is required, but this is good enough for basic tests. > Another approach would be to migrate this on touch, but that is probably > slightly more difficult. The advantage would be that on multiple > migrations it would follow. And it would be a bit slower for > the initial case. Migrate what on touch? Talking mainly about kernel memory structures, task_struct, mm, vmas, page tables, kernel stack, etc. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>