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 99143C433E7 for ; Fri, 16 Oct 2020 15:19:14 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B115A208E4 for ; Fri, 16 Oct 2020 15:19:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B115A208E4 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 129696B0070; Fri, 16 Oct 2020 11:19:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0B1596B0071; Fri, 16 Oct 2020 11:19:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EBC23940009; Fri, 16 Oct 2020 11:19:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0181.hostedemail.com [216.40.44.181]) by kanga.kvack.org (Postfix) with ESMTP id B9DAD6B0070 for ; Fri, 16 Oct 2020 11:19:11 -0400 (EDT) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 1BCFA8249980 for ; Fri, 16 Oct 2020 15:19:11 +0000 (UTC) X-FDA: 77378146902.06.fog30_06161202721e Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin06.hostedemail.com (Postfix) with ESMTP id EC68110260983 for ; Fri, 16 Oct 2020 15:19:10 +0000 (UTC) X-HE-Tag: fog30_06161202721e X-Filterd-Recvd-Size: 5248 Received: from h3cspam02-ex.h3c.com (smtp.h3c.com [60.191.123.50]) by imf50.hostedemail.com (Postfix) with ESMTP for ; Fri, 16 Oct 2020 15:19:09 +0000 (UTC) Received: from h3cspam02-ex.h3c.com (localhost [127.0.0.2] (may be forged)) by h3cspam02-ex.h3c.com with ESMTP id 09GDKlC8011053 for ; Fri, 16 Oct 2020 21:20:47 +0800 (GMT-8) (envelope-from tian.xianting@h3c.com) Received: from DAG2EX01-BASE.srv.huawei-3com.com ([10.8.0.64]) by h3cspam02-ex.h3c.com with ESMTPS id 09GDKblJ010960 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 16 Oct 2020 21:20:37 +0800 (GMT-8) (envelope-from tian.xianting@h3c.com) Received: from DAG2EX03-BASE.srv.huawei-3com.com (10.8.0.66) by DAG2EX01-BASE.srv.huawei-3com.com (10.8.0.64) 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 21:20:41 +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 21:20:41 +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: AQHWo29cMaRbAMdQE0ycFn5GylDeeqmZnPOAgACJFdD//4YYAIAAiVZw Date: Fri, 16 Oct 2020 13:20:41 +0000 Message-ID: <8a25eacf4b37460897911ade338754d3@h3c.com> References: <20201016033952.1924-1-tian.xianting@h3c.com> <20201016120749.GG22589@dhcp22.suse.cz> <9a2b772b13f84bdd9517b17d8d72aa89@h3c.com> <20201016130208.GI22589@dhcp22.suse.cz> In-Reply-To: <20201016130208.GI22589@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 09GDKblJ010960 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 I understood what you said :) But whether it is proper to check reschedule in every loop when lock is tak= en?=20 By the way, I did not met a issue for this , I just learn this code and com= e up with one possible optimization based my understanding. -----Original Message----- From: Michal Hocko [mailto:mhocko@suse.com]=20 Sent: Friday, October 16, 2020 9:02 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 12:48:23, Tianxianting wrote: > Thanks, my understanding is, > In shrink_slab(), do_shrink_slab() will do the real reclaim work, which w= ill occupy current cpu and consume more cpu time, so we need to trigger a r= eschedule after reclaim. > But if it jumps to 'out' label, that means we don't do the reclaim work a= t this time, it won't cause other thread getting starvation, so we don't ne= ed to call cond_resched() in this case. > Is it right? You are almost right. But consider situation when the lock is taken for qui= te some time. do_shrink_slab cannot make any forward progress and effective= lly busy loop. Unless the caller does cond_resched it might cause soft lock= ups. Anyway let me try to ask again. Why does would this be any problem that des= erves a fix? >=20 > -----Original Message----- > From: Michal Hocko [mailto:mhocko@suse.com] > Sent: Friday, October 16, 2020 8:08 PM > To: tianxianting (RD) > Cc: akpm@linux-foundation.org; linux-mm@kvack.org;=20 > linux-kernel@vger.kernel.org > Subject: Re: [PATCH] mm: vmscan: avoid a unnecessary reschedule in=20 > shrink_slab() >=20 > 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(). >=20 > Your changelog doesn't explain why this is not needed or undesirable. Do = you see any actual problem? >=20 > The point of this code is to provide a deterministic scheduling point reg= ardless of the shrinker_rwsew. >=20 > >=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 > > 100644 > > --- a/mm/vmscan.c > > +++ b/mm/vmscan.c > > @@ -687,8 +687,9 @@ static unsigned long shrink_slab(gfp_t gfp_mask, in= t nid, > > } > > =20 > > up_read(&shrinker_rwsem); > > -out: > > + > > cond_resched(); > > +out: > > return freed; > > } > > =20 > > -- > > 2.17.1 > >=20 >=20 > -- > Michal Hocko > SUSE Labs -- Michal Hocko SUSE Labs