On Thu, Aug 24, 2017 at 11:30:50AM +0200, Michal Hocko wrote: > On Thu 24-08-17 14:45:46, Joonsoo Kim wrote: > > From: Joonsoo Kim <iamjoonsoo....@lge.com> > > > > Freepage on ZONE_HIGHMEM doesn't work for kernel memory so it's not that > > important to reserve. When ZONE_MOVABLE is used, this problem would > > theorectically cause to decrease usable memory for GFP_HIGHUSER_MOVABLE > > allocation request which is mainly used for page cache and anon page > > allocation. So, fix it. > > I do not really understand what is the problem you are trying to fix. > Yes the memory is reserved for a higher priority consumer and that is > deliberate AFAICT. Just consider that an OOM victim wants to make > further progress and rely on memory reserve while doing > GFP_HIGHUSER_MOVABLE request. > > So what is the real problem you are trying to address here?
If the system has the both, ZONE_HIGHMEM and ZONE_MOVABLE, ZONE_HIGHMEM will reserve the memory for ZONE_MOVABLE request. However, they are consumed by nearly equivalent priority consumer who uses GFP_HIGHMEM + GFP_MOVABLE. In that case, reserved memory in ZONE_HIGHMEM would not be used and it means just waste of the memory. This patch try to fix it to nullify reserving memory in ZONE_HIGHMEM. And, I think that all this problem is caused by the complex code in lowmem reserve calculation. So, did some clean-up. Thanks.