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
