Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp1715061pxu; Thu, 17 Dec 2020 17:26:38 -0800 (PST) X-Google-Smtp-Source: ABdhPJzJiF6T02z7E0DsdellRjAnXob+S1hGm+KBaBWQRjOx73Bri6dU2y4/EUX1wrVKChIK/S0i X-Received: by 2002:a17:907:60a:: with SMTP id wp10mr1726642ejb.205.1608254798444; Thu, 17 Dec 2020 17:26:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1608254798; cv=none; d=google.com; s=arc-20160816; b=DE8fVsynJ/Cp6J2vpUbz/Oqm9UEqvKYWf8//wYWwW/ovqZynaZUgt0Um7BFttU6oL8 aBIvZY2l26VXULQ2V6BXfDXV+1QqBcTkW7vmNBPSFZ329H5QGjx+CZrkGbKoQ1NNJGYw s3MGmKt9O9rienVrVE22o8j0nGthl4JlG0QORWEUk3keFdsEfPS2But8djlR2/gNAT5U 7n+d7WiMAJDvk+uv7Oynowjl2OQBH6deBcllz7JOHX8aYK7u0CtuuxuSFETGVoExfSfm NSY+PZkvjvecR7VuYS6U89WyU0wUah+PjTGjLdHwt3pKncOprKI6bw+ug33qdwG83nqN jnUA== 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; bh=Z1hKh2ioCXVlRuu/CAO/uz2KkgSaFJuLauDPbdKDdwQ=; b=c29NtXIVLDia8w3AmpVUisNkt+U7DuqGHAmZgD9eTnGIWqnI8YCRzsr3GVIOfgFn1z uw07MS9xR0ZM99S6TNVCEvUh+Qly2AdXFv8TIT5I6qafmxnSGVcFPgbdAxNvcqfxXA7y +rrj6ST6DVDxQfwx6MqsAw1cNHfb1yy3O2xRcHFcVmE3/vLJjxe9v35l8wDeSk39WBCF ad+8MO9aQrFOxzfntePcx8gNZKo1ET0XzYAyzJrT6+wYKoHNfQCOmPf/hn3CXB+LaKWL sNZFCm6DGwptbZbFKqEerF/++mlH4bVFGQ0zkHuN5ytVRm86QCD0YYc3abZ51oX0r6sx LdKw== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r13si5357046edq.603.2020.12.17.17.26.15; Thu, 17 Dec 2020 17:26:38 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732226AbgLRBK3 (ORCPT + 99 others); Thu, 17 Dec 2020 20:10:29 -0500 Received: from mail108.syd.optusnet.com.au ([211.29.132.59]:60594 "EHLO mail108.syd.optusnet.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730792AbgLRBK3 (ORCPT ); Thu, 17 Dec 2020 20:10:29 -0500 Received: from dread.disaster.area (pa49-179-6-140.pa.nsw.optusnet.com.au [49.179.6.140]) by mail108.syd.optusnet.com.au (Postfix) with ESMTPS id B51871B00B3; Fri, 18 Dec 2020 12:09:44 +1100 (AEDT) Received: from dave by dread.disaster.area with local (Exim 4.92.3) (envelope-from ) id 1kq4Gu-0055zP-E0; Fri, 18 Dec 2020 12:09:28 +1100 Date: Fri, 18 Dec 2020 12:09:28 +1100 From: Dave Chinner To: Yang Shi Cc: Roman Gushchin , Kirill Tkhai , Shakeel Butt , Johannes Weiner , Michal Hocko , Andrew Morton , Linux MM , Linux FS-devel Mailing List , Linux Kernel Mailing List Subject: Re: [v2 PATCH 7/9] mm: vmscan: don't need allocate shrinker->nr_deferred for memcg aware shrinkers Message-ID: <20201218010928.GB1199812@dread.disaster.area> References: <20201214223722.232537-1-shy828301@gmail.com> <20201214223722.232537-8-shy828301@gmail.com> <20201215030528.GN3913616@dread.disaster.area> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.3 cv=YKPhNiOx c=1 sm=1 tr=0 cx=a_idp_d a=uDU3YIYVKEaHT0eX+MXYOQ==:117 a=uDU3YIYVKEaHT0eX+MXYOQ==:17 a=kj9zAlcOel0A:10 a=zTNgK-yGK50A:10 a=pGLkceISAAAA:8 a=7-415B0cAAAA:8 a=KvEUY9y020M9keOLPwQA:9 a=CjuIK1q_8ugA:10 a=-RoEEKskQ1sA:10 a=biEYGPWJfzWAr4FL6Ov7:22 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Dec 17, 2020 at 04:56:48PM -0800, Yang Shi wrote: > On Tue, Dec 15, 2020 at 3:07 PM Yang Shi wrote: > > > This guarantees that only the shrinker instances taht have a > > > correctly set up memcg attached to them will have the > > > SHRINKER_MEMCG_AWARE flag set. Hence in all the rest of the shrinker > > > code, we only ever need to check for SHRINKER_MEMCG_AWARE to > > > determine what we should do.... > > > > Thanks. I see your point. We could move the memcg specific details > > into prealloc_memcg_shrinker(). > > > > It seems we have to acquire shrinker_rwsem before we check and modify > > SHIRNKER_MEMCG_AWARE bit if we may clear it. > > Hi Dave, > > Is it possible that shrinker register races with shrinker unregister? > It seems impossible to me by a quick visual code inspection. But I'm > not a VFS expert so I'm not quite sure. Uh, if you have a shrinker racing to register and unregister, you've got a major bug in your object initialisation/teardown code. i.e. calling reagister/unregister at the same time for the same shrinker is a bug, pure and simple. Cheers, Dave. -- Dave Chinner david@fromorbit.com