lkml.org 
[lkml]   [2017]   [Aug]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] mm/page_alloc: don't reserve ZONE_HIGHMEM for ZONE_MOVABLE request
    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@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.

    \
     
     \ /
      Last update: 2017-08-25 02:15    [W:2.683 / U:0.060 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site