Hello, Apart from the "Rethinking NUMA" topic which I have proposed, I would like to attend 2018 LSFMM to discuss following different topics. A. HMM: (Jerome Glisse, John Hubbard, Michal Hocko) I am interested in discussing future plans for HMM (including HMM CDM) including improvement to mmu_notifier framework carrying more context into it's callback etc. B. HugeTLB: (Mike Kravetz, Michal Hocko) I am interested in discussing about anything related to HugeTLB page migration, SW/HW poisoning of HugeTLB pages including how to handle memory failures in a smaller section of the HugeTLB page. I am also interested in anything related to runtime gigantic HugeTLB pages allocation and it's migration/poisoning etc. C. CMA (Mike Kravetz, Laura Abbott, Joonsoo Kim) 1. Supporting hotplug memory as a CMA region There are situations where a platform identified specific PFN range can only be used for some low level debug/tracing purpose. The same PFN range must be shared between multiple guests on a need basis, hence its logical to expect the range to be hot add/removable in each guest. But once available and online in the guest, it would require a sort of guarantee of a large order allocation (almost the entire range) into the memory to use it for aforesaid purpose. Plugging the memory as ZONE_MOVABLE with MIGRATE_CMA makes sense in this scenario but its not supported at the moment. This basically extends the idea of relaxing CMA reservation and declaration restrictions as pointed by Mike Kravetz. 2. Adding NUMA Adding NUMA tracking information to individual CMA areas and use it for alloc_cma() interface. In POWER8 KVM implementation, guest HPT (Hash Page Table) is allocated from a predefined CMA region. NUMA aligned allocation for HPT for any given guest VM can help improve performance. 3. Reducing CMA allocation failures CMA allocation failures are primarily because of not being unable to isolate or migrate the given PFN range (Inside alloc_contig_range). Is there a way to reduce the failure chances ? D. MAP_CONTIG (Mike Kravetz, Laura Abbott, Michal Hocko) I understand that a recent RFC from Mike Kravetz got debated but without any conclusion about the viability to add MAP_CONTIG option for the user space to request large contiguous physical memory. I will be really interested to discuss any future plans on how kernel can help user space with large physical contiguous memory if need arises. (MAP_CONTIG RFC https://lkml.org/lkml/2017/10/3/992) - Anshuman -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
