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=-9.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 EF354C433DF for ; Fri, 16 Oct 2020 12:48:51 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id DFC94207E8 for ; Fri, 16 Oct 2020 12:48:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DFC94207E8 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=h3c.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id EC1FA900003; Fri, 16 Oct 2020 08:48:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E73A7900002; Fri, 16 Oct 2020 08:48:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DAF45900003; Fri, 16 Oct 2020 08:48:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0050.hostedemail.com [216.40.44.50]) by kanga.kvack.org (Postfix) with ESMTP id C068E900002 for ; Fri, 16 Oct 2020 08:48:49 -0400 (EDT) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 7E8018249980 for ; Fri, 16 Oct 2020 12:48:49 +0000 (UTC) X-FDA: 77377767978.18.neck77_500fba12721d Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin18.hostedemail.com (Postfix) with ESMTP id 59F8C10238C98 for ; Fri, 16 Oct 2020 12:48:49 +0000 (UTC) X-HE-Tag: neck77_500fba12721d X-Filterd-Recvd-Size: 3782 Received: from h3cspam02-ex.h3c.com (smtp.h3c.com [60.191.123.50]) by imf30.hostedemail.com (Postfix) with ESMTP for ; Fri, 16 Oct 2020 12:48:46 +0000 (UTC) Received: from DAG2EX02-BASE.srv.huawei-3com.com ([10.8.0.65]) by h3cspam02-ex.h3c.com with ESMTPS id 09GCmK77095507 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 16 Oct 2020 20:48:20 +0800 (GMT-8) (envelope-from tian.xianting@h3c.com) Received: from DAG2EX03-BASE.srv.huawei-3com.com (10.8.0.66) by DAG2EX02-BASE.srv.huawei-3com.com (10.8.0.65) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Fri, 16 Oct 2020 20:48:23 +0800 Received: from DAG2EX03-BASE.srv.huawei-3com.com ([fe80::5d18:e01c:bbbd:c074]) by DAG2EX03-BASE.srv.huawei-3com.com ([fe80::5d18:e01c:bbbd:c074%7]) with mapi id 15.01.1713.004; Fri, 16 Oct 2020 20:48:23 +0800 From: Tianxianting To: Michal Hocko CC: "akpm@linux-foundation.org" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" Subject: RE: [PATCH] mm: vmscan: avoid a unnecessary reschedule in shrink_slab() Thread-Topic: [PATCH] mm: vmscan: avoid a unnecessary reschedule in shrink_slab() Thread-Index: AQHWo29cMaRbAMdQE0ycFn5GylDeeqmZnPOAgACJFdA= Date: Fri, 16 Oct 2020 12:48:23 +0000 Message-ID: <9a2b772b13f84bdd9517b17d8d72aa89@h3c.com> References: <20201016033952.1924-1-tian.xianting@h3c.com> <20201016120749.GG22589@dhcp22.suse.cz> In-Reply-To: <20201016120749.GG22589@dhcp22.suse.cz> Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.99.141.128] x-sender-location: DAG2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-DNSRBL: X-MAIL:h3cspam02-ex.h3c.com 09GCmK77095507 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: Thanks, my understanding is, In shrink_slab(), do_shrink_slab() will do the real reclaim work, which wil= l occupy current cpu and consume more cpu time, so we need to trigger a res= chedule after reclaim. But if it jumps to 'out' label, that means we don't do the reclaim work at = this time, it won't cause other thread getting starvation, so we don't need= to call cond_resched() in this case. Is it right? -----Original Message----- From: Michal Hocko [mailto:mhocko@suse.com]=20 Sent: Friday, October 16, 2020 8:08 PM To: tianxianting (RD) Cc: akpm@linux-foundation.org; linux-mm@kvack.org; linux-kernel@vger.kernel= .org Subject: Re: [PATCH] mm: vmscan: avoid a unnecessary reschedule in shrink_s= lab() On Fri 16-10-20 11:39:52, Xianting Tian wrote: > In shrink_slab(), it directly goes to 'out' label only when it can't=20 > get the lock of shrinker_rwsew. In this case, it doesn't do the real=20 > work of shrinking slab, so we don't need trigger a reschedule by=20 > cond_resched(). Your changelog doesn't explain why this is not needed or undesirable. Do yo= u see any actual problem? The point of this code is to provide a deterministic scheduling point regar= dless of the shrinker_rwsew. >=20 > Signed-off-by: Xianting Tian > --- > mm/vmscan.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) >=20 > diff --git a/mm/vmscan.c b/mm/vmscan.c index 466fc3144..676e97b28=20 > 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -687,8 +687,9 @@ static unsigned long shrink_slab(gfp_t gfp_mask, int = nid, > } > =20 > up_read(&shrinker_rwsem); > -out: > + > cond_resched(); > +out: > return freed; > } > =20 > -- > 2.17.1 >=20 --=20 Michal Hocko SUSE Labs