Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp1911579ybt; Thu, 2 Jul 2020 17:49:37 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxxfWj1K/l1r+3hyMqS7XfAsBJA8ZGRvkAKGPhL9bZ0ThjEuGxSqdrcxIF283vo96EU8d3z X-Received: by 2002:a17:906:c04d:: with SMTP id bm13mr21570867ejb.321.1593737376810; Thu, 02 Jul 2020 17:49:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593737376; cv=none; d=google.com; s=arc-20160816; b=UIG/+NZ/f21pDblBPbHnaZ+56L+GSngCy1+ju/CAmAkAFo0AWIaYlukoIxvSxPwd/C 43rGnrjuW+rZQYDgMRp2lFhPtZnpKywnhBcfZ1RiMCqX7eONmrvsSRMYu4h0DvfxzMC5 l9LbPHvs3Qg/eQ5gvLzRs9WWbSDOteYYcFDX30QDhX7UpW+msOI9W2ZPgRvzneuEPp5I xuPKO5F0rDcHH3Ke/FvtavQJkOXr0Mrpeh+U32PfU+kjbqT3LpLEgiU2QDQnqKqHwKaZ UTv+6nP8n13egKeGfP97WDiTefUPyBSdZk11QM5m26GS2T6ynVBK0VY3lxEdXEF5rpIM MhDw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=QubtygT6CHPqxIkPsZey+WL7TuPuIYxqs13CLNXIeHw=; b=pcco0pfIRGgPMr+pk0XLMPAK345s5Lws40YvXuu/s8oLFHqTcAJQM3UlFqiLt01ozm y49i++Yp//yOCKJgoHo+n2vy79glcC8gHGkHIdweOEoTpO7xejEKYoLp8FLWAy/3GqWn +IELXbwHRmSs+nyy+gOdz/O04Hf1VRWgBM9C9GrpzSN1066QSY646HoVcguXYitGS8H7 bgG4epIUhm9APlELz4lSHQ1z2HUnvYAW1AT5evNg+azMpgssNaGXhfgzLEw43cGlhBTN swiwTBUM8JphQjyuLuCXYYuZVcfXBKe0tBX1fcORMVhMGcWdkS+Fm0+7Ukm7ldsS92k9 z7DA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Tiv0Wo8V; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h12si6823045ejx.234.2020.07.02.17.49.14; Thu, 02 Jul 2020 17:49:36 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Tiv0Wo8V; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726474AbgGCAsA (ORCPT + 99 others); Thu, 2 Jul 2020 20:48:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58336 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726336AbgGCAr7 (ORCPT ); Thu, 2 Jul 2020 20:47:59 -0400 Received: from mail-qv1-xf43.google.com (mail-qv1-xf43.google.com [IPv6:2607:f8b0:4864:20::f43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4EB4BC08C5C1 for ; Thu, 2 Jul 2020 17:47:59 -0700 (PDT) Received: by mail-qv1-xf43.google.com with SMTP id p7so13597342qvl.4 for ; Thu, 02 Jul 2020 17:47:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=QubtygT6CHPqxIkPsZey+WL7TuPuIYxqs13CLNXIeHw=; b=Tiv0Wo8V7BGJ98NUyieGZaCTDAHig6wZyVeaeiVFIhMeO7PL64VLLJBKgiGnmMAWOb lIqVjjiMrLzx6Bq8hBzWRDDQN07NPH6sC6vkNbqGv4Q3vLWGezl/uVoGQqE3hiApBORw BByd9gH5KUFCjtxCAGSwM1yN8t+O+LK3sJqVf/84Sg11eSAdQJ3/R+iapUrOTzX1SmrK Jgegw6uQzJNoHzVgfPNpl+730XkD8fClhCTriVjZG5k2alnF5LFTDfaLx/rMMpNcTj1i ic8IQ+h9FAVX8PG81NiOqwqSgN/NG0iGI2Nx6ugBbSxoCFaqCYDazWouLUL3fZM7YTly 35IQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=QubtygT6CHPqxIkPsZey+WL7TuPuIYxqs13CLNXIeHw=; b=ZOLsN3skqJCqQazm5/MhVkuJfsK1AE1xcnAcGTvTKpb01SUhLOWi94JxXeGHKEPXqQ dt+ayP+ZVBwIgyQCP9pUgfFCgs0YWztWEwPhDNhD66FeLrQvcC4IwyrAgkQQvVTKA+rD IpOm+oBfxfWQ9wZbLw117lMSJ9fs3ZNE9dmAGL442N10Q8WqfXEarByCl4PFeNiy6vMA 0wwLwtu/iiMwIYY+qSeT0UbEh4gHfGS33k7Lc4T3CnedU5ZpzDwlFgYQoGjNeSWFitVv qndLb8hbQzAqe6lHX5/TZ4crjpqQh4XaKeh/JzTJbpraApg/7Ms2NvFgSUBW546EpuLI H2mQ== X-Gm-Message-State: AOAM533y66DgllmeDovtAfv1GNPLfxLxdjjsk7rJMv/iqQSoyxZ2b11B GbdfKnTlSa2mdtExKn3aOJ7ogJYykdQGfWtx0zs= X-Received: by 2002:a0c:99c5:: with SMTP id y5mr9684766qve.66.1593737278471; Thu, 02 Jul 2020 17:47:58 -0700 (PDT) MIME-Version: 1.0 References: <1592371583-30672-1-git-send-email-iamjoonsoo.kim@lge.com> <1592371583-30672-3-git-send-email-iamjoonsoo.kim@lge.com> <4591b38d-fdd0-e2e6-bf11-6e5669575736@suse.cz> In-Reply-To: <4591b38d-fdd0-e2e6-bf11-6e5669575736@suse.cz> From: Joonsoo Kim Date: Fri, 3 Jul 2020 09:47:47 +0900 Message-ID: Subject: Re: [PATCH v6 2/6] mm/vmscan: protect the workingset on anonymous LRU To: Vlastimil Babka Cc: Andrew Morton , Linux Memory Management List , LKML , Johannes Weiner , Michal Hocko , Hugh Dickins , Minchan Kim , Mel Gorman , kernel-team@lge.com, Joonsoo Kim Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2020=EB=85=84 7=EC=9B=94 2=EC=9D=BC (=EB=AA=A9) =EC=98=A4=EC=A0=84 3:02, Vl= astimil Babka =EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1: > > On 6/17/20 7:26 AM, js1304@gmail.com wrote: > > From: Joonsoo Kim > > Hi, how about a more descriptive subject, such as Hello, > mm/vmscan: add new anonymous pages to inactive LRU list This patch does two things to implement workingset protection. - add new anonymous pages to inactive LRU list - check two reference to activate So, I think that the current subject is more descriptive for this patch. > > In current implementation, newly created or swap-in anonymous page > > is started on active list. Growing active list results in rebalancing > > active/inactive list so old pages on active list are demoted to inactiv= e > > list. Hence, the page on active list isn't protected at all. > > > > Following is an example of this situation. > > > > Assume that 50 hot pages on active list. Numbers denote the number of > > pages on active/inactive list (active | inactive). > > > > 1. 50 hot pages on active list > > 50(h) | 0 > > > > 2. workload: 50 newly created (used-once) pages > > 50(uo) | 50(h) > > > > 3. workload: another 50 newly created (used-once) pages > > 50(uo) | 50(uo), swap-out 50(h) > > > > This patch tries to fix this issue. > > Like as file LRU, newly created or swap-in anonymous pages will be > > inserted to the inactive list. They are promoted to active list if > > enough reference happens. This simple modification changes the above > > example as following. > > > > 1. 50 hot pages on active list > > 50(h) | 0 > > > > 2. workload: 50 newly created (used-once) pages > > 50(h) | 50(uo) > > > > 3. workload: another 50 newly created (used-once) pages > > 50(h) | 50(uo), swap-out 50(uo) > > > > As you can see, hot pages on active list would be protected. > > > > Note that, this implementation has a drawback that the page cannot > > be promoted and will be swapped-out if re-access interval is greater th= an > > the size of inactive list but less than the size of total(active+inacti= ve). > > To solve this potential issue, following patch will apply workingset > > detection that is applied to file LRU some day before. > > detection similar to the one that's already applied to file LRU. Will change! > > v6: Before this patch, all anon pages (inactive + active) are considere= d > > as workingset. However, with this patch, only active pages are consider= ed > > as workingset. So, file refault formula which uses the number of all > > anon pages is changed to use only the number of active anon pages. > > a "v6" note is more suitable for a diffstat area than commit log, but it'= s good > to mention this so drop the 'v6:'? Okay. > > Acked-by: Johannes Weiner > > Signed-off-by: Joonsoo Kim > > Acked-by: Vlastimil Babka Thanks! > One more nit below. > > > --- a/mm/swap.c > > +++ b/mm/swap.c > > @@ -476,23 +476,24 @@ void lru_cache_add(struct page *page) > > EXPORT_SYMBOL(lru_cache_add); > > > > /** > > - * lru_cache_add_active_or_unevictable > > + * lru_cache_add_inactive_or_unevictable > > * @page: the page to be added to LRU > > * @vma: vma in which page is mapped for determining reclaimability > > * > > - * Place @page on the active or unevictable LRU list, depending on its > > + * Place @page on the inactive or unevictable LRU list, depending on i= ts > > * evictability. Note that if the page is not evictable, it goes > > * directly back onto it's zone's unevictable list, it does NOT use a > > * per cpu pagevec. > > */ > > -void lru_cache_add_active_or_unevictable(struct page *page, > > +void lru_cache_add_inactive_or_unevictable(struct page *page, > > struct vm_area_struct *vma) > > { > > + bool unevictable; > > + > > VM_BUG_ON_PAGE(PageLRU(page), page); > > > > - if (likely((vma->vm_flags & (VM_LOCKED | VM_SPECIAL)) !=3D VM_LOC= KED)) > > - SetPageActive(page); > > - else if (!TestSetPageMlocked(page)) { > > + unevictable =3D (vma->vm_flags & (VM_LOCKED | VM_SPECIAL)) =3D=3D= VM_LOCKED; > > + if (unevictable && !TestSetPageMlocked(page)) { > > I guess this could be "if (unlikely(unevictable) && ..." to match the pre= vious > if (likely(evictable)) else ... I will fix it, too. Thanks.