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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 9A1AEC433DB for ; Tue, 16 Mar 2021 02:07:49 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2C7266500C for ; Tue, 16 Mar 2021 02:07:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2C7266500C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A13656B006C; Mon, 15 Mar 2021 22:07:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9C3526B006E; Mon, 15 Mar 2021 22:07:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8B25A6B0070; Mon, 15 Mar 2021 22:07:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0188.hostedemail.com [216.40.44.188]) by kanga.kvack.org (Postfix) with ESMTP id 731246B006C for ; Mon, 15 Mar 2021 22:07:48 -0400 (EDT) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 2796D12DA for ; Tue, 16 Mar 2021 02:07:48 +0000 (UTC) X-FDA: 77924101416.17.A12A367 Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by imf28.hostedemail.com (Postfix) with ESMTP id 0912A2000381 for ; Tue, 16 Mar 2021 02:07:46 +0000 (UTC) IronPort-SDR: 5BQP5Kr2YFRhtiRNJPGpJ6e8iAnbzcPPgKJCdS81YruTYqs7en19QUWHgzpajiK4aJgp8FUq/d 3f+AK90rMiUw== X-IronPort-AV: E=McAfee;i="6000,8403,9924"; a="209107983" X-IronPort-AV: E=Sophos;i="5.81,251,1610438400"; d="scan'208";a="209107983" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Mar 2021 19:07:45 -0700 IronPort-SDR: d2eDvlHl+dgThSXmfUvknY+TyZ1uWkRIbfoaWox9BycBJ4AK71ppXLeGh+u5OdGz3hVAMoHuJ7 IZatz0beOQ6A== X-IronPort-AV: E=Sophos;i="5.81,251,1610438400"; d="scan'208";a="412045481" Received: from unknown (HELO yhuang6-desk1.ccr.corp.intel.com) ([10.239.13.1]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Mar 2021 19:07:40 -0700 From: "Huang, Ying" To: Rik van Riel Cc: Yu Zhao , , 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 , , Subject: Re: [PATCH v1 09/14] mm: multigenerational lru: mm_struct list References: <20210313075747.3781593-1-yuzhao@google.com> <20210313075747.3781593-10-yuzhao@google.com> <048e5e1e977e720c3f9fc536ac54beebcc8319f5.camel@surriel.com> Date: Tue, 16 Mar 2021 10:07:36 +0800 In-Reply-To: <048e5e1e977e720c3f9fc536ac54beebcc8319f5.camel@surriel.com> (Rik van Riel's message of "Mon, 15 Mar 2021 15:40:10 -0400") Message-ID: <87pmzzsvfb.fsf@yhuang6-desk1.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii X-Stat-Signature: gfpj8f36r7hrc6n9nknx64ozxex8jim4 X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 0912A2000381 Received-SPF: none (intel.com>: No applicable sender policy available) receiver=imf28; identity=mailfrom; envelope-from=""; helo=mga01.intel.com; client-ip=192.55.52.88 X-HE-DKIM-Result: none/none X-HE-Tag: 1615860466-980088 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: 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. 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? 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. Best Regards, Huang, Ying