lkml.org 
[lkml]   [2022]   [Jan]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v6 6/9] mm: multigenerational lru: aging
    On Thu, Jan 06, 2022 at 05:12:16PM +0100, Michal Hocko wrote:
    > On Tue 04-01-22 13:22:25, Yu Zhao wrote:
    > > +static struct lru_gen_mm_walk *alloc_mm_walk(void)
    > > +{
    > > + if (!current->reclaim_state || !current->reclaim_state->mm_walk)
    > > + return kvzalloc(sizeof(struct lru_gen_mm_walk), GFP_KERNEL);
    > > +
    > > + return current->reclaim_state->mm_walk;
    > > +}
    > > +
    > > +static void free_mm_walk(struct lru_gen_mm_walk *walk)
    > > +{
    > > + if (!current->reclaim_state || !current->reclaim_state->mm_walk)
    > > + kvfree(walk);
    > > +}
    >
    > Do I get it right that you are allocating from the reclaim context? What
    > prevents this to completely deplete the memory as the reclaim context is
    > PF_MEMALLOC?

    Yes, and in general the same reason zram/zswap/etc. allocate memory in
    the reclaim context: to make more free memory.

    In this case, lru_gen_mm_walk is small (160 bytes); it's per direct
    reclaimer; and direct reclaimers rarely come here, i.e., only when
    kswapd can't keep up in terms of the aging, which is similar to the
    condition where the inactive list is empty for the active/inactive
    lru.

    \
     
     \ /
      Last update: 2022-01-06 22:42    [W:4.073 / U:0.084 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site