Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp4706479pxu; Mon, 21 Dec 2020 21:25:19 -0800 (PST) X-Google-Smtp-Source: ABdhPJzRB9Rq0L4Vydd+Q341yjYPcEiV720992shWTSPBzjPZ093sETmsuiSPXBSl1ZW0kLD+/QJ X-Received: by 2002:a05:6402:2066:: with SMTP id bd6mr18777463edb.211.1608614719545; Mon, 21 Dec 2020 21:25:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1608614719; cv=none; d=google.com; s=arc-20160816; b=ydIwGDxONoXp8J+EW8gK+sHR3FjCC8jymZgLC3x47Gwd/ap/8+nwLuCGlpFRcabS4D 8QAFCLdIXRMPkNHvSOVMT9hQi8sEczE5NuYX2TieU5nRVZ8P61dW15GFNRrbIa55e94k kwUvoxxg2K+Y7fDFTTrVkYVnAy9YGd2gmLElPBku1EmAZgS6+C8PKJu6T41iFQ+40K66 GU7D7igtXqYqcmK7kMCHkSpY0JdrVMCdrxSGtD27vfH/OIWhOO3iXD2ePHNTnnsLC++g Zf3txxc4zyeolsvTwua7ZliBMvdIHj39Wn+E91y3uPGVS/bbsCPpXmjtzP3mc6QzFltX 2jzA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:references:cc:to :subject; bh=5LIFvyyNR77bE2CZjoP9IQrpoyW+bx2PaWbkN+9toiM=; b=SdT+KlbQVmvpqbWrL5NyhsV9XHZVfTz1aLKLuoYq2swnNrvB4PTzqN3l+I5w3VNMqV kDC4dHz2KB5004aALkMpsarsYiPqerxqkXtxR/W+E7Rd4uUUsx1ZiykNMGsi2YqL5R7O 3wLooz47tg/fOhvZmQpKAvesrPBORMJGB2OgS9t4Z9muOegFY3NzJKB/ti+s5/PlBAQk YOn2hzd3B7L9F87/PWE5YkAcus05ZDtMcw0yJW44S1DeJSKt3NNt52N4d9l82a3Eg8Aj iESmXuYFaRGY7k9Wvj4MsJynLWdysNA7CnGw33FDe9k2aLWfPRyecr8Z9XZX6JSCXgX9 icDw== ARC-Authentication-Results: i=1; mx.google.com; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id lw27si10041641ejb.35.2020.12.21.21.24.57; Mon, 21 Dec 2020 21:25:19 -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; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725997AbgLVFXw (ORCPT + 99 others); Tue, 22 Dec 2020 00:23:52 -0500 Received: from out30-45.freemail.mail.aliyun.com ([115.124.30.45]:57898 "EHLO out30-45.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725818AbgLVFXw (ORCPT ); Tue, 22 Dec 2020 00:23:52 -0500 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R731e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04407;MF=alex.shi@linux.alibaba.com;NM=1;PH=DS;RN=8;SR=0;TI=SMTPD_---0UJPXZ7P_1608614586; Received: from IT-FVFX43SYHV2H.local(mailfrom:alex.shi@linux.alibaba.com fp:SMTPD_---0UJPXZ7P_1608614586) by smtp.aliyun-inc.com(127.0.0.1); Tue, 22 Dec 2020 13:23:06 +0800 Subject: Re: [PATCH 1/3] mm/memcg: revise the using condition of lock_page_lruvec function series To: Hugh Dickins Cc: Andrew Morton , Johannes Weiner , Michal Hocko , Vladimir Davydov , cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <1608186532-81218-1-git-send-email-alex.shi@linux.alibaba.com> From: Alex Shi Message-ID: Date: Tue, 22 Dec 2020 13:23:06 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.0; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=gbk Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org ?? 2020/12/22 ????11:01, Hugh Dickins ะด??: > On Thu, 17 Dec 2020, Alex Shi wrote: > >> The series function could be used under lock_page_memcg(), add this and >> a bit style changes following commit_charge(). >> >> Signed-off-by: Alex Shi >> Cc: Hugh Dickins > > This patch, or its intention, > Acked-by: Hugh Dickins > but rewording suggested below, and requested above - > which left me very puzzled before eventually I understood it. > I don't think we need to talk about "a bit style changes", > but the cross-reference to commit_charge() is helpful. > > " > lock_page_lruvec() and its variants are safe to use under the same > conditions as commit_charge(): add lock_page_memcg() to the comment. > " Thanks a lot, Hugh. Yes, your commit log are far more better than mine. :) I will resent with your changes and Ack. Thanks! Alex > >> Cc: Johannes Weiner >> Cc: Michal Hocko >> Cc: Vladimir Davydov >> Cc: Andrew Morton >> Cc: cgroups@vger.kernel.org >> Cc: linux-mm@kvack.org >> Cc: linux-kernel@vger.kernel.org >> --- >> mm/memcontrol.c | 9 +++++---- >> 1 file changed, 5 insertions(+), 4 deletions(-) >> >> diff --git a/mm/memcontrol.c b/mm/memcontrol.c >> index b80328f52fb4..e6b50d068b2f 100644 >> --- a/mm/memcontrol.c >> +++ b/mm/memcontrol.c >> @@ -1345,10 +1345,11 @@ void lruvec_memcg_debug(struct lruvec *lruvec, struct page *page) >> * lock_page_lruvec - lock and return lruvec for a given page. >> * @page: the page >> * >> - * This series functions should be used in either conditions: >> - * PageLRU is cleared or unset >> - * or page->_refcount is zero >> - * or page is locked. >> + * This series functions should be used in any one of following conditions: > > These functions are safe to use under any of the following conditions: > >> + * - PageLRU is cleared or unset >> + * - page->_refcount is zero >> + * - page is locked. > > Remove that full stop... > >> + * - lock_page_memcg() > > ... and, if you wish (I don't care), add full stop at the end of that line. > > Maybe reorder those to the same order as listed in commit_charge(). > Copy its text exactly? I don't think so, actually, I find your wording > (e.g. _refcount is zero) more explicit: good to have both descriptions. > >> */ >> struct lruvec *lock_page_lruvec(struct page *page) >> { >> -- >> 2.29.GIT