From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0B6DAC433E0 for ; Tue, 16 Mar 2021 03:57:09 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7462D65039 for ; Tue, 16 Mar 2021 03:57:08 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7462D65039 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id DB7C86B006C; Mon, 15 Mar 2021 23:57:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D68106B006E; Mon, 15 Mar 2021 23:57:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BE0C26B0070; Mon, 15 Mar 2021 23:57:07 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0098.hostedemail.com [216.40.44.98]) by kanga.kvack.org (Postfix) with ESMTP id 9F4516B006C for ; Mon, 15 Mar 2021 23:57:07 -0400 (EDT) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 4A4456C3A for ; Tue, 16 Mar 2021 03:57:07 +0000 (UTC) X-FDA: 77924376894.07.BCBC951 Received: from mail-io1-f48.google.com (mail-io1-f48.google.com [209.85.166.48]) by imf24.hostedemail.com (Postfix) with ESMTP id CE266A0000FA for ; Tue, 16 Mar 2021 03:57:06 +0000 (UTC) Received: by mail-io1-f48.google.com with SMTP id k2so35773651ioh.5 for ; Mon, 15 Mar 2021 20:57:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=qa8CZwJOeZFJUfkuJ5OjeuaRp9kzYHq6lZBFu2jA+Gw=; b=K6nq/jUY0UMPI4TsIymeF0yspJqJuN1e2Z/ELnVv5em0SXtGDAABy7ex9PGaTNWwSl N1Fq6HTh6rmKDN3STw8c2mhsUy7YH6cKAPaIiEOI9GVz0Lh+liGEC7CSGEnnSG6YIEat JCmYLtK7lOXFqGwBjPrEKy4YWNkKIwX/H+BY9U/nrbu1dIbmOQI49D77iPSweFNlLspI YWzk8P7mgvaos+kVOn3k1gezit5F1w6aSLY0QPGjjqAMCBilHvtlNvjK6pCPt1ufWI3s 0LegBteUZudjGDyj7eQ/2NqYTKnqdQBmHtYLD9yFbEUP3fFmrlJIrh4norJ0TtqqwnSL 641g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=qa8CZwJOeZFJUfkuJ5OjeuaRp9kzYHq6lZBFu2jA+Gw=; b=EXYr32/bZd/k9IUEBv+BH2tqyLeiMtTgPltRSE7PYExgl/0Nm27UOjaZV+eFfvDCI7 WTA8iW7aAftLIL4EqMgcs70jVHIRuiKgluKntws87i8fVYhjetNHIGke1yPUfbtW6S9O NpdWI4GmxNkQP+P7E88hQnvVlY0QsRKEN63sMDWPXtw6+QQJ7BKt5MrJxGTi8QbYcE2v JYLYPhnZPcQPjO4H8OB/4SAL3tcfg6FHajpfp1mA8CZs1ms6qkjbgGEtHPTAKyC4UIsw y5lXjPxWn01nF8L67VVVhTjjXVR0MlqmkA0Ubaqj1/6wE+WKu85TWomQ27EkrS8cP2lJ lZow== X-Gm-Message-State: AOAM5339uA+CPFNjY8yM+PyxH6gPY70fPnmT99CQK+1hODdWS6BKciss SbT0pLPeLBcYBtcWexmQ/XMNJqktG7AhvKz4 X-Google-Smtp-Source: ABdhPJwNp0pcHttp9QW2yxQMvwq4OEcBYKJA/vZFr+ygOrf1wEU5FGRF8D/a5+9oMEQRgREz3ckO7Q== X-Received: by 2002:a5d:9f4a:: with SMTP id u10mr1932727iot.186.1615867026137; Mon, 15 Mar 2021 20:57:06 -0700 (PDT) Received: from google.com ([2620:15c:183:200:d825:37a2:4b55:995f]) by smtp.gmail.com with ESMTPSA id y13sm6447282ioc.36.2021.03.15.20.57.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 Mar 2021 20:57:05 -0700 (PDT) Date: Mon, 15 Mar 2021 21:57:00 -0600 From: Yu Zhao To: "Huang, Ying" Cc: Rik van Riel , linux-mm@kvack.org, Alex Shi , Andrew Morton , Dave Hansen , Hillf Danton , Johannes Weiner , Joonsoo Kim , Matthew Wilcox , Mel Gorman , Michal Hocko , Roman Gushchin , Vlastimil Babka , Wei Yang , Yang Shi , linux-kernel@vger.kernel.org, page-reclaim@google.com Subject: Re: [PATCH v1 09/14] mm: multigenerational lru: mm_struct list Message-ID: References: <20210313075747.3781593-1-yuzhao@google.com> <20210313075747.3781593-10-yuzhao@google.com> <048e5e1e977e720c3f9fc536ac54beebcc8319f5.camel@surriel.com> <87pmzzsvfb.fsf@yhuang6-desk1.ccr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87pmzzsvfb.fsf@yhuang6-desk1.ccr.corp.intel.com> X-Stat-Signature: 74znjhoc5xswa7ecsf9xwe3pha9tafo3 X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: CE266A0000FA Received-SPF: none (google.com>: No applicable sender policy available) receiver=imf24; identity=mailfrom; envelope-from=""; helo=mail-io1-f48.google.com; client-ip=209.85.166.48 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1615867026-171876 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Mar 16, 2021 at 10:07:36AM +0800, Huang, Ying wrote: > Rik van Riel writes: > > > On Sat, 2021-03-13 at 00:57 -0700, Yu Zhao wrote: > > > >> +/* > >> + * After pages are faulted in, they become the youngest generation. > >> They must > >> + * go through aging process twice before they can be evicted. After > >> first scan, > >> + * their accessed bit set during initial faults are cleared and they > >> become the > >> + * second youngest generation. And second scan makes sure they > >> haven't been used > >> + * since the first. > >> + */ > > > > I have to wonder if the reductions in OOM kills and > > low-memory tab discards is due to this aging policy > > change, rather than from the switch to virtual scanning. There are no policy changes per se. The current page reclaim also scans a faulted-in page at least twice before it can reclaim it. That said, the new aging yields a better overall result because it discovers every page that has been referenced since the last scan, in addition to what Ying has mentioned. The current page scan stops stops once it finds enough candidates, which may seem more efficiently, but actually pays the price for not finding the best. > If my understanding were correct, the temperature of the processes is > considered in addition to that of the individual pages. That is, the > pages of the processes that haven't been scheduled after the previous > scanning will not be scanned. I guess that this helps OOM kills? Yes, that's correct. > If so, how about just take advantage of that information for OOM killing > and page reclaiming? For example, if a process hasn't been scheduled > for long time, just reclaim its private pages. This is how it works. Pages that haven't been scanned grow older automatically because those that have been scanned will be tagged with younger generation numbers. Eviction does bucket sort based on generation numbers and attacks the oldest.