[LSF/MM ATTEND] Requests to attend MM Summit 2018

[Anshuman Khandual <khandual@linux.vnet.ibm.com>]

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@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>