Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp1646455pxb; Fri, 20 Nov 2020 15:17:23 -0800 (PST) X-Google-Smtp-Source: ABdhPJwOGB4v3mTfQM8Xy26N0Ex657QblISNfsjVPUOZJP9VjeC1ia1zYb1Oco67imO0lDuQBLx8 X-Received: by 2002:a17:906:af49:: with SMTP id ly9mr34761639ejb.238.1605914243142; Fri, 20 Nov 2020 15:17:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605914243; cv=none; d=google.com; s=arc-20160816; b=xi4M33QdV1aEiOvyBRgcQi2RhaKBo/FxwTjkH8LJxY+llHGYskPV+uv3W/5cf25JtA vDIJ/D+vzSwEoPBiy0nN825fOLAVWs36iP9GEcoXroSnGz9H/9E9NYoxgTgYj+tEmbZA INMrb49swM2eX4vnN72H2JQ1tUT3j1kFlz18QoNvzRaJlMa0DWtCujP9qfHMEwyGb9LN gMpRl/gelDDTddjLkmCXmvwbix07felRFLhSd0lr+3f0aml4f6vOWjG81j7JkqX1Tg63 P6P/QIjyPnj7K4empl8rAvsowoNEqbfd/1lT5OFwaUqpQugiyvOZmEPRIA8aBPRJ4dbH lp0A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=KnOrsaaHjD69zx1PCgYTzWmaf5noYHYW41YqIimdDj0=; b=P+rjCj+j1eYd/7hExR+7X3S4wZZPvMUt3x3f7kS634c57dUURuh34H6Cgu6SjxRQiQ CbNtWUgRXKOf/Vso884FBTGHPmfTy6Ixu1eJAo8x/m1IZtaKQOKNNSQUKiBzrhlhVgDB AnHoHgcg2XpBF/i/gISCdbaHH5/1iPkU0m905Zws5W+qEh3xg+Yho4iTzf5Fwyl9HOMP yZZF38aBotKCGVSL8KgZWydchuvL1hSD9j43H4xNLPo8Z4BkjVVGAwnGSpvtnWHFi6km rI5q31rT+lva/17jbfN5JlJMCtmhdgKdWs5YYtHwFft0t3aqGLaQKvEn6ullRIhdO437 nObw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=korg header.b=XwzkJGGV; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c95si3270321edf.197.2020.11.20.15.17.00; Fri, 20 Nov 2020 15:17:23 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=korg header.b=XwzkJGGV; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728897AbgKTXNL (ORCPT + 99 others); Fri, 20 Nov 2020 18:13:11 -0500 Received: from mail.kernel.org ([198.145.29.99]:43860 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727728AbgKTXNK (ORCPT ); Fri, 20 Nov 2020 18:13:10 -0500 Received: from localhost.localdomain (c-73-231-172-41.hsd1.ca.comcast.net [73.231.172.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id A46182240B; Fri, 20 Nov 2020 23:13:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1605913989; bh=kGZ3tY895qvwswmX8ewkKR4DXUjrQEmGUbS1BBPrqao=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=XwzkJGGVKL7FuVt1qEFS7X+RiwM4EE3PuWURqNAeDOPoiHV6zVUJh9Jl9k3+FUX4z rXZAAZQxHYcyfX4+/8AZtT294HTEP5Zkxew1QheWaJLhx+xkCwD4T3xE/4FXWbzie3 RAX3/B7W0MAt35ANy8G7CB1OzKeOr75KHDQblY5Q= Date: Fri, 20 Nov 2020 15:13:07 -0800 From: Andrew Morton To: Alex Shi Cc: Hugh Dickins , Yu Zhao , Vlastimil Babka , Michal Hocko , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH next] mm/vmscan: __isolate_lru_page_prepare clean up Message-Id: <20201120151307.4d9e3ef092ba01a325db7ce2@linux-foundation.org> In-Reply-To: <1605859413-53864-1-git-send-email-alex.shi@linux.alibaba.com> References: <1605859413-53864-1-git-send-email-alex.shi@linux.alibaba.com> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 20 Nov 2020 16:03:33 +0800 Alex Shi wrote: > The function just return 2 results, so use a 'switch' to deal with its > result is unnecessary, and simplify it to a bool func as Vlastimil > suggested. > > Also removed 'goto' in using by reusing list_move(). > > ... > > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -1540,7 +1540,7 @@ unsigned int reclaim_clean_pages_from_list(struct zone *zone, > */ > int __isolate_lru_page_prepare(struct page *page, isolate_mode_t mode) > { > - int ret = -EBUSY; > + int ret = false; > > /* Only take pages on the LRU. */ > if (!PageLRU(page)) > @@ -1590,7 +1590,7 @@ int __isolate_lru_page_prepare(struct page *page, isolate_mode_t mode) > if ((mode & ISOLATE_UNMAPPED) && page_mapped(page)) > return ret; > > - return 0; > + return true; > } The resulting __isolate_lru_page_prepare() is rather unpleasing. - Why return an int and not a bool? - `int ret = false' is a big hint that `ret' should have bool type! - Why not just remove `ret' and do `return false' in all those `return ret' places? - The __isolate_lru_page_prepare() kerneldoc still says "returns 0 on success, -ve errno on failure".