lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAAmzW4OGThMZk2sRrboZt6nx82CiphKVFpxLGaXFXLB7WYfd3Q@mail.gmail.com>
Date:   Thu, 2 Apr 2020 14:50:28 +0900
From:   Joonsoo Kim <js1304@...il.com>
To:     Johannes Weiner <hannes@...xchg.org>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Linux Memory Management List <linux-mm@...ck.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Michal Hocko <mhocko@...nel.org>,
        Hugh Dickins <hughd@...gle.com>,
        Minchan Kim <minchan@...nel.org>,
        Vlastimil Babka <vbabka@...e.cz>,
        Mel Gorman <mgorman@...hsingularity.net>, kernel-team@....com,
        Joonsoo Kim <iamjoonsoo.kim@....com>
Subject: Re: [PATCH v4 6/8] mm/swap: implement workingset detection for
 anonymous LRU

2020년 3월 24일 (화) 오후 3:25, Joonsoo Kim <js1304@...il.com>님이 작성:
>
> 2020년 3월 24일 (화) 오전 2:17, Johannes Weiner <hannes@...xchg.org>님이 작성:
> >
> > On Mon, Mar 23, 2020 at 02:52:10PM +0900, js1304@...il.com wrote:
> > > From: Joonsoo Kim <iamjoonsoo.kim@....com>
> > >
> > > This patch implements workingset detection for anonymous LRU.
> > > All the infrastructure is implemented by the previous patches so this patch
> > > just activates the workingset detection by installing/retrieving
> > > the shadow entry.
> > >
> > > Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@....com>
> > > ---
> > >  include/linux/swap.h |  6 ++++++
> > >  mm/memory.c          |  7 ++++++-
> > >  mm/swap_state.c      | 20 ++++++++++++++++++--
> > >  mm/vmscan.c          |  7 +++++--
> > >  4 files changed, 35 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/include/linux/swap.h b/include/linux/swap.h
> > > index 273de48..fb4772e 100644
> > > --- a/include/linux/swap.h
> > > +++ b/include/linux/swap.h
> > > @@ -408,6 +408,7 @@ extern struct address_space *swapper_spaces[];
> > >  extern unsigned long total_swapcache_pages(void);
> > >  extern void show_swap_cache_info(void);
> > >  extern int add_to_swap(struct page *page);
> > > +extern void *get_shadow_from_swap_cache(swp_entry_t entry);
> > >  extern int add_to_swap_cache(struct page *page, swp_entry_t entry,
> > >                       gfp_t gfp, void **shadowp);
> > >  extern int __add_to_swap_cache(struct page *page, swp_entry_t entry);
> > > @@ -566,6 +567,11 @@ static inline int add_to_swap(struct page *page)
> > >       return 0;
> > >  }
> > >
> > > +static inline void *get_shadow_from_swap_cache(swp_entry_t entry)
> > > +{
> > > +     return NULL;
> > > +}
> > > +
> > >  static inline int add_to_swap_cache(struct page *page, swp_entry_t entry,
> > >                                       gfp_t gfp_mask, void **shadowp)
> > >  {
> > > diff --git a/mm/memory.c b/mm/memory.c
> > > index 5f7813a..91a2097 100644
> > > --- a/mm/memory.c
> > > +++ b/mm/memory.c
> > > @@ -2925,10 +2925,15 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
> > >                       page = alloc_page_vma(GFP_HIGHUSER_MOVABLE, vma,
> > >                                                       vmf->address);
> > >                       if (page) {
> > > +                             void *shadow;
> > > +
> > >                               __SetPageLocked(page);
> > >                               __SetPageSwapBacked(page);
> > >                               set_page_private(page, entry.val);
> > > -                             lru_cache_add_anon(page);
> > > +                             shadow = get_shadow_from_swap_cache(entry);
> > > +                             if (shadow)
> > > +                                     workingset_refault(page, shadow);
> >
> > Hm, this is calling workingset_refault() on a page that isn't charged
> > to a cgroup yet. That means the refault stats and inactive age counter
> > will be bumped incorrectly in the root cgroup instead of the real one.
>
> Okay.
>
> > > +                             lru_cache_add(page);
> > >                               swap_readpage(page, true);
> > >                       }
> > >               } else {
> >
> > You need to look up and remember the shadow entry at the top and call
> > workingset_refault() after mem_cgroup_commit_charge() has run.
>
> Okay. I will call workingset_refault() after charging.
>
> I completely missed that workingset_refault() should be called after charging.
> workingset_refault() in __read_swap_cache_async() also has the same problem.
>
> > It'd be nice if we could do the shadow lookup for everybody in
> > lookup_swap_cache(), but that's subject to race conditions if multiple
> > faults on the same swap page happen in multiple vmas concurrently. The
> > swapcache bypass scenario is only safe because it checks that there is
> > a single pte under the mmap sem to prevent forking. So it looks like
> > you have to bubble up the shadow entry through swapin_readahead().
>
> The problem looks not that easy. Hmm...
>
> In current code, there is a large time gap between the shadow entries
> are poped up and the page is charged to the memcg, especially,
> for readahead-ed pages. We cannot maintain the shadow entries of
> the readahead-ed pages until the pages are charged.
>
> My plan to solve this problem is propagating the charged mm to
> __read_swap_cache_async(), like as file cache, charging when
> the page is added on to the swap cache and calling workingset_refault()
> there. Charging will only occur if:
>
> 1. faulted page
> 2. readahead-ed page with the shadow entry for the same memcg
>
> Also, readahead only happens when shadow entry's memcg is the same
> with the charged memcg. If not the same, it's mostly not ours so
> readahead isn't needed.
>
> Please let me know how you think of the feasibility of this idea.

Hello, Johannes.

Could you let me know your opinion about the idea above?
In fact, since your reply is delayed, I completed the solution about the
above idea. If you want, I will submit it first. Then, we could discuss
the solution more easily.

Thanks.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ