Received: by 2002:a05:6a10:9e8c:0:0:0:0 with SMTP id y12csp3379350pxx; Mon, 2 Nov 2020 07:25:16 -0800 (PST) X-Google-Smtp-Source: ABdhPJzCs0VDGa6YBPI7kt9OB4LjE51A7DqCjoRvjCI7BXFzrxggThLZ/Rsp2LJ2y4z5JcQcZwg+ X-Received: by 2002:aa7:cb1a:: with SMTP id s26mr17073291edt.219.1604330716381; Mon, 02 Nov 2020 07:25:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1604330716; cv=none; d=google.com; s=arc-20160816; b=FVX+SOjLqoSrD8/grvRj+v7ncLc1n55oR+soMSt9mFhZAE/3xukmC2607gjZL8qSft x+MgSzbLRiaYJPpRHcwgGIAjUB9W6bNSNNwGOJa8QeVlNU/eMkIfy6DSrMso9M8Z7O+P RVGqQehkU24Sa17dNYmOyDjWgLF4i3OI96was8lAOp+sOEErZma254/HqbnjDP5csLye Laei1iYBstukhr4onENMCH9YrPR7FYyF1yLO0o1hdYxkGEUd//8K9+FWz+GTCfVqnaCS yvO/wcQn4fO7N99eeBSQq8nuXM+KQ/mQfmoDSvT050EUCmoLmAx8luLebuGLSIvbgG6D AeVQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=PZfLygvPchTUSgGMmFZPk8zJRPc7y3a0+u5vclYWa+g=; b=DkNiwp4YOqkZj1wTUdxMjGmvTKdH1IN5wYqFOVgXkkJVlhIwaNRQZgwo33uiMclYDG NM2RNIw9cFGVOg2Bj6W1aptK81At+i/yeqmG1/1NE5JW1qMmg7u0txnCrxfmUq2CiKKZ UivyTkw69K9YLL/dg57AKu0hW1e2uyFqSvA3ISM0/E0mkgYaNiRWyk2JOBPK4AUsiFxz 8dz4Kpeqq+KLHYXt4Il2i+rolFjZt6Zm4+UUKbPpPGV4tE5pCbyvUCocWmwTgE+iaj+V nLKHp7USHzF0L+TtzA+A/TA+R340P4ruNJBU2hiqwyy8g4gDPXnKLC8n6gJ0glknQUFe MXJw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@cmpxchg-org.20150623.gappssmtp.com header.s=20150623 header.b=bAkYwaoc; 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=cmpxchg.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r26si11897403ejb.420.2020.11.02.07.24.53; Mon, 02 Nov 2020 07:25:16 -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=@cmpxchg-org.20150623.gappssmtp.com header.s=20150623 header.b=bAkYwaoc; 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=cmpxchg.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726520AbgKBPWd (ORCPT + 99 others); Mon, 2 Nov 2020 10:22:33 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57078 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726419AbgKBPWc (ORCPT ); Mon, 2 Nov 2020 10:22:32 -0500 Received: from mail-qt1-x842.google.com (mail-qt1-x842.google.com [IPv6:2607:f8b0:4864:20::842]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EF963C0617A6 for ; Mon, 2 Nov 2020 07:22:31 -0800 (PST) Received: by mail-qt1-x842.google.com with SMTP id t5so832776qtp.2 for ; Mon, 02 Nov 2020 07:22:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=PZfLygvPchTUSgGMmFZPk8zJRPc7y3a0+u5vclYWa+g=; b=bAkYwaocuGeef7r/WOYoDUSYpYjQDgRDpirAbBQA4pgs0hzQ0GiYmrYxa29dxnVHRF WxZ+s5OiKNjfk7VuV+xQNYKlAGD4juHOKsM0ZetbZkYA9t1Tbh1k2izLHb7ERccLcgHm GCCABAf8ThtuwtqKtEcG6HvFonuEEIP0GHWjilwMZYs78mM8ItctpBi0UBxTd5qcNaAs QdZ7tgIjuj20hncEA5VgCavYzeW6I9e9gAOIUgoiUtVovsIhhie+0DjaKZnVF0kJxI0J Jf02bfDygNUlJuqZ865wjaIfGmJK7DpfTtDj0KZDfr56i5YflC13w1YJT5czGz7ws46t JTtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=PZfLygvPchTUSgGMmFZPk8zJRPc7y3a0+u5vclYWa+g=; b=o7We8Ebd4Eval8BAatw7JOMdIEpaVywB9ha9x0KuEQFEk/wHV7/Ug+7+8VVaGwkyih w4XgsXw+GBpuX1q1+ueq9Ord+rLpcyDMtCmy3B9fFZuEkHl56rOrt2Vd5nSaa6d+QDDP wVa/aqEp7uxVlEWpp5njZXbf77Rji41d5KMJrBOYV0F8T5bxcq1gfnmx1xCBZYDeeatS UHfrFsG1MqATPXoZArqIGGFZU/43Cz+Y9e5XAj2K2a6dro/LIo7v9L9o/81EtFjjkdQU xs7o+0Vos5UGUl0i2kUvUTwMjNFldtIT07Agw27wXMiGFbOwjZNIs/6IJptCd4r1NPdX wdgg== X-Gm-Message-State: AOAM533z2Gb3SaRIIJ5YClp8naik/AqsKSVSzGt1L4IpaGvL31XUzCUp CcFGvqHJ+LG3wcEIYIbJomTiPQ== X-Received: by 2002:aed:2941:: with SMTP id s59mr14633752qtd.387.1604330550876; Mon, 02 Nov 2020 07:22:30 -0800 (PST) Received: from localhost ([2620:10d:c091:480::1:2f6e]) by smtp.gmail.com with ESMTPSA id p2sm3861044qkk.34.2020.11.02.07.22.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Nov 2020 07:22:30 -0800 (PST) Date: Mon, 2 Nov 2020 10:20:45 -0500 From: Johannes Weiner To: Alex Shi Cc: akpm@linux-foundation.org, mgorman@techsingularity.net, tj@kernel.org, hughd@google.com, khlebnikov@yandex-team.ru, daniel.m.jordan@oracle.com, willy@infradead.org, lkp@intel.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, shakeelb@google.com, iamjoonsoo.kim@lge.com, richard.weiyang@gmail.com, kirill@shutemov.name, alexander.duyck@gmail.com, rong.a.chen@intel.com, mhocko@suse.com, vdavydov.dev@gmail.com, shy828301@gmail.com Subject: Re: [PATCH v20 17/20] mm/swap.c: serialize memcg changes in pagevec_lru_move_fn Message-ID: <20201102152045.GJ724984@cmpxchg.org> References: <1603968305-8026-1-git-send-email-alex.shi@linux.alibaba.com> <1603968305-8026-18-git-send-email-alex.shi@linux.alibaba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1603968305-8026-18-git-send-email-alex.shi@linux.alibaba.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 29, 2020 at 06:45:02PM +0800, Alex Shi wrote: > Hugh Dickins' found a memcg change bug on original version: > If we want to change the pgdat->lru_lock to memcg's lruvec lock, we have > to serialize mem_cgroup_move_account during pagevec_lru_move_fn. The > possible bad scenario would like: > > cpu 0 cpu 1 > lruvec = mem_cgroup_page_lruvec() > if (!isolate_lru_page()) > mem_cgroup_move_account > > spin_lock_irqsave(&lruvec->lru_lock <== wrong lock. > > So we need TestClearPageLRU to block isolate_lru_page(), that serializes > the memcg change. and then removing the PageLRU check in move_fn callee > as the consequence. > > __pagevec_lru_add_fn() is different from the others, because the pages > it deals with are, by definition, not yet on the lru. TestClearPageLRU > is not needed and would not work, so __pagevec_lru_add() goes its own > way. > > Reported-by: Hugh Dickins > Signed-off-by: Alex Shi > Acked-by: Hugh Dickins > Cc: Andrew Morton > Cc: linux-mm@kvack.org > Cc: linux-kernel@vger.kernel.org Acked-by: Johannes Weiner