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=-8.1 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, 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 60E9AC33CA8 for ; Mon, 13 Jan 2020 09:56:10 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 226D82081E for ; Mon, 13 Jan 2020 09:56:09 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=yandex-team.ru header.i=@yandex-team.ru header.b="XmwXyts9" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 226D82081E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=yandex-team.ru Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id CF9928E0005; Mon, 13 Jan 2020 04:56:05 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C816A8E0003; Mon, 13 Jan 2020 04:56:05 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B4A0A8E0005; Mon, 13 Jan 2020 04:56:05 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0145.hostedemail.com [216.40.44.145]) by kanga.kvack.org (Postfix) with ESMTP id 9A8438E0003 for ; Mon, 13 Jan 2020 04:56:05 -0500 (EST) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with SMTP id 4EDE8B9E9 for ; Mon, 13 Jan 2020 09:56:05 +0000 (UTC) X-FDA: 76372155090.05.dirt20_34fe85403cb55 X-HE-Tag: dirt20_34fe85403cb55 X-Filterd-Recvd-Size: 4966 Received: from forwardcorp1j.mail.yandex.net (forwardcorp1j.mail.yandex.net [5.45.199.163]) by imf48.hostedemail.com (Postfix) with ESMTP for ; Mon, 13 Jan 2020 09:56:04 +0000 (UTC) Received: from mxbackcorp2j.mail.yandex.net (mxbackcorp2j.mail.yandex.net [IPv6:2a02:6b8:0:1619::119]) by forwardcorp1j.mail.yandex.net (Yandex) with ESMTP id 76AB82E0B1E; Mon, 13 Jan 2020 12:56:01 +0300 (MSK) Received: from vla5-58875c36c028.qloud-c.yandex.net (vla5-58875c36c028.qloud-c.yandex.net [2a02:6b8:c18:340b:0:640:5887:5c36]) by mxbackcorp2j.mail.yandex.net (mxbackcorp/Yandex) with ESMTP id 2kBEcgvne1-u0Luud4o; Mon, 13 Jan 2020 12:56:01 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex-team.ru; s=default; t=1578909361; bh=tfWEf85Tg93V8jfj/kRU8NVn5c39kp85P+atbWGt+tM=; h=In-Reply-To:Message-ID:From:Date:References:To:Subject:Cc; b=XmwXyts9sUV12nUE4N1YSxf4tvNZDuR2Ax8TvGvRhsh26jDwzbTHtJ99/Mlp6VqtB /AYBkrEzUXcCxSzePb6NELBf292iLyFGmNdmZlMZGMCS1/0JVKkw2VGFtnDeFj+HEA Vxi2Izzl7c6DKKT3UT00eui5YKjhKoMkMkTm2wwY= Authentication-Results: mxbackcorp2j.mail.yandex.net; dkim=pass header.i=@yandex-team.ru Received: from dynamic-red.dhcp.yndx.net (dynamic-red.dhcp.yndx.net [2a02:6b8:0:40c:8448:fbcc:1dac:c863]) by vla5-58875c36c028.qloud-c.yandex.net (smtpcorp/Yandex) with ESMTPSA id 6iOpZA3Dpj-txX0Y9uN; Mon, 13 Jan 2020 12:56:00 +0300 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client certificate not present) Subject: Re: [PATCH v7 02/10] mm/memcg: fold lru_lock in lock_page_lru To: Alex Shi , cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, mgorman@techsingularity.net, tj@kernel.org, hughd@google.com, daniel.m.jordan@oracle.com, yang.shi@linux.alibaba.com, willy@infradead.org, shakeelb@google.com, hannes@cmpxchg.org Cc: Michal Hocko , Vladimir Davydov References: <1577264666-246071-1-git-send-email-alex.shi@linux.alibaba.com> <1577264666-246071-3-git-send-email-alex.shi@linux.alibaba.com> <36d7e390-a3d1-908c-d181-4a9e9c8d3d98@yandex-team.ru> <952d02c2-8aa5-40bb-88bb-c43dee65c8bc@linux.alibaba.com> From: Konstantin Khlebnikov Message-ID: <2ba8a04e-d8e0-1d50-addc-dbe1b4d8e0f1@yandex-team.ru> Date: Mon, 13 Jan 2020 12:55:59 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <952d02c2-8aa5-40bb-88bb-c43dee65c8bc@linux.alibaba.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-CA Content-Transfer-Encoding: quoted-printable 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 13/01/2020 12.45, Alex Shi wrote: >=20 >=20 > =E5=9C=A8 2020/1/10 =E4=B8=8B=E5=8D=884:49, Konstantin Khlebnikov =E5=86= =99=E9=81=93: >> On 25/12/2019 12.04, Alex Shi wrote: >>> =C2=A0From the commit_charge's explanations and mem_cgroup_commit_ch= arge >>> comments, as well as call path when lrucare is ture, The lru_lock is >>> just to guard the task migration(which would be lead to move_account) >>> So it isn't needed when !PageLRU, and better be fold into PageLRU to >>> reduce lock contentions. >>> >>> Signed-off-by: Alex Shi >>> Cc: Johannes Weiner >>> Cc: Michal Hocko >>> Cc: Matthew Wilcox >>> Cc: Vladimir Davydov >>> Cc: Andrew Morton >>> Cc: cgroups@vger.kernel.org >>> Cc: linux-mm@kvack.org >>> Cc: linux-kernel@vger.kernel.org >>> --- >>> =C2=A0 mm/memcontrol.c | 9 ++++----- >>> =C2=A0 1 file changed, 4 insertions(+), 5 deletions(-) >>> >>> diff --git a/mm/memcontrol.c b/mm/memcontrol.c >>> index c5b5f74cfd4d..0ad10caabc3d 100644 >>> --- a/mm/memcontrol.c >>> +++ b/mm/memcontrol.c >>> @@ -2572,12 +2572,11 @@ static void cancel_charge(struct mem_cgroup *= memcg, unsigned int nr_pages) >>> =C2=A0 =C2=A0 static void lock_page_lru(struct page *page, int *isol= ated) >>> =C2=A0 { >>> -=C2=A0=C2=A0=C2=A0 pg_data_t *pgdat =3D page_pgdat(page); >>> - >>> -=C2=A0=C2=A0=C2=A0 spin_lock_irq(&pgdat->lru_lock); >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (PageLRU(page)) { >>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 pg_data_t *pgdat =3D page= _pgdat(page); >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 struct lruvec= *lruvec; >>> =C2=A0 +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 spin_lock_irq(&pg= dat->lru_lock); >> >> That's wrong. Here PageLRU must be checked again under lru_lock. > Hi, Konstantin, >=20 > For logical remain, we can get the lock and then release for !PageLRU. > but I still can figure out the problem scenario. Would like to give mor= e hints? That's trivial race: page could be isolated from lru between if (PageLRU(page)) and spin_lock_irq(&pgdat->lru_lock); >=20 >=20 >> >> >> Also I don't like these functions: >> - called lock/unlock but actually also isolates >> - used just once >> - pgdat evaluated twice >=20 > That's right. I will fold these functions into commit_charge. >=20 > Thanks > Alex >=20