> I tried to build a test module to recreate the problem, but the test > module doesn't exhibit the bug. I assume that is because there is > something different with the context from which the allocation is > happening. I tried to follow the code path of alloc_pages_node() to find > out what that difference might be, but didn't succeed. Hence I attached a > boiled down version of my changes that still demonstrate the problem. > It's really a one line change in kvm. Yes it looks harmless. > > I was hoping that someone with real numa hardware and kvm capabilities > would be able to test this tiny patch in order to find out if the problem > lies with the fake numa or indeed the context of the allocation so I could > focus my efforts on the right target. One way you could test that yourself would be to fake real NUMA. As in hardcode a very simple SRAT into drivers/acpi/numa.c that splits your memory/cores in half. That should be about equivalent to the real thing on the Linux level. Originally fake numa was like this too, but that got changed later. > Alternatively, I'd also be greatful if anybody had any idea why > alloc_pages_node() would behave differently in different context and what > that difference would be. Maybe someone set a task memory policy? I thought NUMA support for that got added to KVM qemu at some point. You can check with stracing qemu or by dumping the policies of the kvm task. Actually you specified GFP_THISNODE which should avoid this, but maybe there is a bug somewhere. Very likely there is in fact from your description. But I can't see it either from a quick look. Did you try it without GFP_THISNODE? -Andi -- ak@xxxxxxxxxxxxxxx -- Speaking for myself only. -- To unsubscribe from this list: send the line "unsubscribe linux-numa" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
