Re: RE(4): FW: [LSF/MM/BPF TOPIC] SMDK inspired MM changes for CXL

[Gregory Price <gregory.price@memverge.com>]

On Fri, Mar 24, 2023 at 05:48:08PM +0900, Kyungsan Kim wrote:
> 
> Indeed, we tried the approach. It was able to allocate a kernel context from ZONE_MOVABLE using GFP_MOVABLE.
> However, we think it would be a bad practice for the 2 reasons.
> 1. It causes oops and system hang occasionally due to kernel page migration while swap or compaction. 
> 2. Literally, the design intention of ZONE_MOVABLE is to a page movable. So, we thought allocating a kernel context from the zone hurts the intention.
> 
> Allocating a kernel context out of ZONE_EXMEM is unmovable.
>   a kernel context -  alloc_pages(GFP_EXMEM,)

What is the specific use case of this?  If the answer is flexibility in
low-memory situations, why wouldn't the kernel simply change to free up
ZONE_NORMAL (swapping user memory, migrating user memory, etc) and
allocate as needed?

I could see allocating kernel memory from local memory expanders
(directly attached to local CXL port), but I can't think of a case where
it would be preferable for kernel resources to live on remote memory.
Since local memory expanders are static devices, there shouldn't be a
great need for hotplug, which means the memory could be mapped
ZONE_NORMAL without issue.

> Allocating a user context out of ZONE_EXMEM is movable.
>   a user context - mmap(,,MAP_EXMEM,) - syscall - alloc_pages(GFP_EXMEM | GFP_MOVABLE,)
> This is how ZONE_EXMEM supports the two cases.
> 

Is it intended for a user to explicitly request MAP_EXMEM for it to get
used at all?  As in, if i simply mmap() without MAP_EXMEM, will it
remain unutilized?

~Gregory