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.kim@xxxxxxx> > > > > 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. -- 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>
