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=-10.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham 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 4D090C433B4 for ; Thu, 22 Apr 2021 20:17:51 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9FD2C6137D for ; Thu, 22 Apr 2021 20:17:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9FD2C6137D 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 056326B0072; Thu, 22 Apr 2021 16:17:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 02D586B0087; Thu, 22 Apr 2021 16:17:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E5E526B0093; Thu, 22 Apr 2021 16:17:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0191.hostedemail.com [216.40.44.191]) by kanga.kvack.org (Postfix) with ESMTP id C97886B0072 for ; Thu, 22 Apr 2021 16:17:49 -0400 (EDT) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 01D49182331A6 for ; Thu, 22 Apr 2021 20:17:48 +0000 (UTC) X-FDA: 78061113816.05.3F3D0D3 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by imf09.hostedemail.com (Postfix) with ESMTP id F3A8A6000137 for ; Thu, 22 Apr 2021 20:17:41 +0000 (UTC) IronPort-SDR: RrVg+C2XBVOtpnn7MZXlXmofCTSRDjMvTWXLBmLYLxkNVhocxhW58ULwLaQ5+JFZCyN4jcVpeJ YoENcjDC2+Mg== X-IronPort-AV: E=McAfee;i="6200,9189,9962"; a="196023950" X-IronPort-AV: E=Sophos;i="5.82,243,1613462400"; d="scan'208";a="196023950" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Apr 2021 13:17:42 -0700 IronPort-SDR: cGN1FiVr7rRdcgpr4pABfyQNa2TqI8SwHnvF0YAmf33j9kE5ZlJ1fIFzUW0D4ngpaW3CUaR7lt idK8Dg5iHbyA== X-IronPort-AV: E=Sophos;i="5.82,243,1613462400"; d="scan'208";a="428105376" Received: from schen9-mobl.amr.corp.intel.com ([10.254.72.4]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Apr 2021 13:17:42 -0700 Subject: Re: [RFC] mm/vmscan.c: avoid possible long latency caused by too_many_isolated() To: Yu Zhao , Xing Zhengjun Cc: akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, ying.huang@intel.com, Shakeel Butt , Michal Hocko , wfg@mail.ustc.edu.cn References: <20210416023536.168632-1-zhengjun.xing@linux.intel.com> <7b7a1c09-3d16-e199-15d2-ccea906d4a66@linux.intel.com> From: Tim Chen Message-ID: Date: Thu, 22 Apr 2021 13:17:37 -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-Queue-Id: F3A8A6000137 X-Stat-Signature: rk4aerqkzxiyx4ymeb8arqnzmb11fy3r X-Rspamd-Server: rspam02 Received-SPF: none (linux.intel.com>: No applicable sender policy available) receiver=imf09; identity=mailfrom; envelope-from=""; helo=mga03.intel.com; client-ip=134.134.136.65 X-HE-DKIM-Result: none/none X-HE-Tag: 1619122661-668845 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 10:13 AM, Yu Zhao wrote: > @@ -3302,6 +3252,7 @@ static bool throttle_direct_reclaim(gfp_t gfp_mask, struct zonelist *zonelist, > unsigned long try_to_free_pages(struct zonelist *zonelist, int order, > gfp_t gfp_mask, nodemask_t *nodemask) > { > + int nr_cpus; > unsigned long nr_reclaimed; > struct scan_control sc = { > .nr_to_reclaim = SWAP_CLUSTER_MAX, > @@ -3334,8 +3285,17 @@ unsigned long try_to_free_pages(struct zonelist *zonelist, int order, > set_task_reclaim_state(current, &sc.reclaim_state); > trace_mm_vmscan_direct_reclaim_begin(order, sc.gfp_mask); > > + nr_cpus = current_is_kswapd() ? 0 : num_online_cpus(); > + while (nr_cpus && !atomic_add_unless(&pgdat->nr_reclaimers, 1, nr_cpus)) { > + if (schedule_timeout_killable(HZ / 10)) 100 msec seems like a long time to wait. The original code in shrink_inactive_list choose 100 msec sleep because the sleep happens only once in the while loop and 100 msec was used to check for stalling. In this case the loop can go on for a while and the #reclaimers can go down below the sooner than 100 msec. Seems like it should be checked more often. Tim > + return SWAP_CLUSTER_MAX; > + } > + > nr_reclaimed = do_try_to_free_pages(zonelist, &sc); > > + if (nr_cpus) > + atomic_dec(&pgdat->nr_reclaimers); > + > trace_mm_vmscan_direct_reclaim_end(nr_reclaimed); > set_task_reclaim_state(current, NULL); >