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=-8.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=unavailable 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 2A85BC433B4 for ; Sun, 25 Apr 2021 00:48:34 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id AF6F661481 for ; Sun, 25 Apr 2021 00:48:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AF6F661481 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 EB7E36B0036; Sat, 24 Apr 2021 20:48:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E8F7C6B006C; Sat, 24 Apr 2021 20:48:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D2EEC6B006E; Sat, 24 Apr 2021 20:48:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0102.hostedemail.com [216.40.44.102]) by kanga.kvack.org (Postfix) with ESMTP id B70A86B0036 for ; Sat, 24 Apr 2021 20:48:32 -0400 (EDT) Received: from smtpin38.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 75DD05DF4 for ; Sun, 25 Apr 2021 00:48:32 +0000 (UTC) X-FDA: 78069053664.38.4A4D299 Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by imf18.hostedemail.com (Postfix) with ESMTP id EEFCE2000242 for ; Sun, 25 Apr 2021 00:48:31 +0000 (UTC) IronPort-SDR: vyd75gf8XVF+efnd7YhfQnaYdjDW3sKMcs60IuKCR4voq4RFhj+zltpsdUuf4Q/VvU9Gb7Cvhm kE3lX+shipaw== X-IronPort-AV: E=McAfee;i="6200,9189,9964"; a="176322652" X-IronPort-AV: E=Sophos;i="5.82,249,1613462400"; d="scan'208";a="176322652" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Apr 2021 17:48:26 -0700 IronPort-SDR: EeMfR+hV1QrmnisxPdxkxo1LcIoKYFOjOAP13eXwTZTXMao2BRqg949nKNtJRVaNoSTvjOuMH+ /lr9129zEQHg== X-IronPort-AV: E=Sophos;i="5.82,249,1613462400"; d="scan'208";a="428890013" Received: from yhuang6-desk1.sh.intel.com (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; 24 Apr 2021 17:48:24 -0700 From: "Huang, Ying" To: Yu Zhao Cc: Xing Zhengjun , akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, tim.c.chen@linux.intel.com, Shakeel Butt , Michal Hocko , wfg@mail.ustc.edu.cn Subject: Re: [RFC] mm/vmscan.c: avoid possible long latency caused by too_many_isolated() References: <20210416023536.168632-1-zhengjun.xing@linux.intel.com> <7b7a1c09-3d16-e199-15d2-ccea906d4a66@linux.intel.com> <7a0fecab-f9e1-ad39-d55e-01e574a35484@linux.intel.com> Date: Sun, 25 Apr 2021 08:48:22 +0800 In-Reply-To: (Yu Zhao's message of "Fri, 23 Apr 2021 14:23:38 -0600") Message-ID: <87fszfxk89.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-Rspamd-Queue-Id: EEFCE2000242 X-Stat-Signature: bma8ijxi97ntj8tiwzmq38kwkjyou666 X-Rspamd-Server: rspam02 Received-SPF: none (intel.com>: No applicable sender policy available) receiver=imf18; identity=mailfrom; envelope-from=""; helo=mga17.intel.com; client-ip=192.55.52.151 X-HE-DKIM-Result: none/none X-HE-Tag: 1619311711-726440 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: Yu Zhao writes: [snip] > @@ -2966,13 +2938,20 @@ static void shrink_zones(struct zonelist *zonelist, struct scan_control *sc) > /* need some check for avoid more shrink_zone() */ > } > > - /* See comment about same check for global reclaim above */ > - if (zone->zone_pgdat == last_pgdat) > - continue; > - last_pgdat = zone->zone_pgdat; > shrink_node(zone->zone_pgdat, sc); > } > > + if (last_pgdat) > + atomic_dec(&last_pgdat->nr_reclaimers); > + else if (should_retry) { > + /* wait a bit for the reclaimer. */ > + if (!schedule_timeout_killable(HZ / 10)) Once we reached here, even accidentally, the caller needs to sleep at least 100ms. How about use a semaphore for pgdat->nr_reclaimers? Then the sleeper can be waken up when the resource is considered enough. Best Regards, Huang, Ying > + goto retry; > + > + /* We are about to die and free our memory. Return now. */ > + sc->nr_reclaimed += SWAP_CLUSTER_MAX; > + } > + > /* > * Restore to original mask to avoid the impact on the caller if we > * promoted it to __GFP_HIGHMEM. [snip]