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=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 514F0C433ED for ; Thu, 22 Apr 2021 21:03:04 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B49B161417 for ; Thu, 22 Apr 2021 21:03:03 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B49B161417 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 306738D0002; Thu, 22 Apr 2021 17:03:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 290758D0001; Thu, 22 Apr 2021 17:03:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 130348D0002; Thu, 22 Apr 2021 17:03:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0201.hostedemail.com [216.40.44.201]) by kanga.kvack.org (Postfix) with ESMTP id E532E8D0001 for ; Thu, 22 Apr 2021 17:03:02 -0400 (EDT) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 160756124 for ; Thu, 22 Apr 2021 21:03:02 +0000 (UTC) X-FDA: 78061227804.22.822E05C Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by imf01.hostedemail.com (Postfix) with ESMTP id E58285001537 for ; Thu, 22 Apr 2021 21:02:56 +0000 (UTC) IronPort-SDR: jcfjBNeW7+yIslj+RINZzz0CA17svNuWnbybYAlG+9rO5/5lWA2UnLJH2frsW0yABaR0WQaTlE eiIsbetWyd/A== X-IronPort-AV: E=McAfee;i="6200,9189,9962"; a="257280318" X-IronPort-AV: E=Sophos;i="5.82,243,1613462400"; d="scan'208";a="257280318" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Apr 2021 14:02:58 -0700 IronPort-SDR: BwxzlXGV6rYqGB38hPzKe9g1Uto1iOH898kNrc+p0jorGkvST92B6KWznxaC3wfi80KzXV+44q Q0BjTIddDrEw== X-IronPort-AV: E=Sophos;i="5.82,243,1613462400"; d="scan'208";a="455951434" Received: from schen9-mobl.amr.corp.intel.com ([10.254.72.4]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Apr 2021 14:02:57 -0700 Subject: Re: [RFC] mm/vmscan.c: avoid possible long latency caused by too_many_isolated() To: Yu Zhao , Xing Zhengjun Cc: Andrew Morton , Linux-MM , linux-kernel , Huang Ying , Michal Hocko , wfg@mail.ustc.edu.cn, Shakeel Butt , Hugh Dickins References: <20210416023536.168632-1-zhengjun.xing@linux.intel.com> <7b7a1c09-3d16-e199-15d2-ccea906d4a66@linux.intel.com> <2ea3318a-b17c-ec4c-5425-cb93e079a994@linux.intel.com> From: Tim Chen Message-ID: Date: Thu, 22 Apr 2021 14:02:57 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: E58285001537 X-Stat-Signature: rkhfcnf9jq11tozjaoptxtnbkjqbemom Received-SPF: none (linux.intel.com>: No applicable sender policy available) receiver=imf01; identity=mailfrom; envelope-from=""; helo=mga06.intel.com; client-ip=134.134.136.31 X-HE-DKIM-Result: none/none X-HE-Tag: 1619125376-490174 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 4/22/21 1:57 PM, Yu Zhao wrote: > On Thu, Apr 22, 2021 at 2:38 PM Tim Chen wrote: >> >> >> >> On 4/22/21 1:30 PM, Yu Zhao wrote: >>> >>> HZ/10 is purely arbitrary but that's ok because we assume normally >>> nobody hits it. If you do often, we need to figure out why and how not >>> to hit it so often. >>> >> >> Perhaps Zhengjun can test the proposed fix in his test case to see if the timeout value >> makes any difference. > > Shakeel has another test to stress page reclaim to a point that the > kernel can livelock for two hours because of a large number of > concurrent reclaimers stepping on each other. He might be able to > share that test with you in case you are interested. That will be great. Yes, we are interested to have the test. Tim > > Also it's Hugh who first noticed that migration can isolate many pages > and in turn block page reclaim. He might be able to help too, in case > you are interested in the interaction between migration and page > reclaim. > > Thanks. >