On Wednesday 05 June 2013 11:56:30 Michal Hocko wrote: > On Wed 05-06-13 11:32:15, Frank Mehnert wrote: > [...] > > > Thank you very much for your help. As I said, this problem happens _only_ > > with NUMA_BALANCING enabled. I understand that you treat the VirtualBox > > code as untrusted but the reason for the problem is that some assumption > > is obviously not met: The VirtualBox code assumes that the memory it > > allocates using case A and case B is > > > > 1. always present and > > 2. will always be backed by the same phyiscal memory > > > > over the entire life time. Enabling NUMA_BALANCING seems to make this > > assumption false. I only want to know why. > > As I said earlier. Both the manual node migration and numa_fault handler > do not migrate pages with elevated ref count (your A case) and pages > that are not on the LRU. So if your Referenced pages might be on the LRU > then you probably have to look into numamigrate_isolate_page and do an > exception for PageReserved pages. But I am a bit suspicious this is the > cause because the reclaim doesn't consider PageReserved pages either so > they could get reclaimed. Or maybe you have handled that path in your > kernel. Thanks, I will also investigate into this direction. > Or the other option is that you depend on a timing or something like > that which doesn't hold anymore. That would be hard to debug though. > > > I see, you don't believe me. I will add more code to the kernel logging > > which pages were migrated. > > Simple test for PageReserved flag in numamigrate_isolate_page should > tell you more. > > This would cover the migration part. Another potential problem could be > that the page might get unmapped and marked for the numa fault (see > do_numa_page). So maybe your code just assumes that the page even > doesn't get unmapped? Exactly, that's the assumption -- therefore all these vm_flags tricks. If this assumption is wrong or not always true, can this requirement (page is _never_ unmapped) be met at all? Thanks, Frank -- Dr.-Ing. Frank Mehnert | Software Development Director, VirtualBox ORACLE Deutschland B.V. & Co. KG | Werkstr. 24 | 71384 Weinstadt, Germany Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Geschäftsführer: Jürgen Kunz Komplementärin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Geschäftsführer: Alexander van der Ven, Astrid Kepper, Val Maher
Attachment:
signature.asc
Description: This is a digitally signed message part.