Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp3544229pxu; Tue, 15 Dec 2020 09:22:11 -0800 (PST) X-Google-Smtp-Source: ABdhPJzXAKOxM/Ehb63xnomEyGIoCSi44jLvv/KFsAgNptNzWOV8hB+0eth31qCDjbKrGiM7RgDz X-Received: by 2002:a50:a6de:: with SMTP id f30mr3505765edc.30.1608052931152; Tue, 15 Dec 2020 09:22:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1608052931; cv=none; d=google.com; s=arc-20160816; b=Fksw0YlP4MrrvFuobv9SbIFcKpfczgBsuv7QZUQp/T1kSbCXYTl92x01D0831CIzch N4USauVY8pRElrCZM7zUXBarUGnkKzyK3Z/uuEfIEh528ci24I44NLnwKXFWc0pc15m5 MlxzevpB7pV7/hnQk1hs4vHdk/DZKp7l56cHAH0lNheM43oDmxTPMkjt7SOcnbOgqSfI cQs8UBN+wjIQSL3fm42fmVBbH89QQKbBIxXo9YGURmg/Yg2OtSV0ImeymyJuCmA1JInY W8DcVFhIXxosJb77FC+VDth+X2eElZq7+Bdr5PljonEZosYdpsm1/JWzlmcAyafBr2hs BDSg== 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=yKB5P3mmMeccCVq/i2dQ6a1JB3M5e9Un7Ow5i/UnWnM=; b=Xs3OXjlvKpux2+VXuPxB56hokiw+W0S/r+enWHEBbqXSq9mRxmUGbpRBbifX9biYgB btC/yKPSdwkYrMJZoeWl3b7fLPQZtDjRJA2JDRr8/aw56TqVVDN2HaoRkpDN0HYDLvoj D8ncQZF+Vm3FRAlBrgxRLG0vHtniNkzA0AFGReEiW3NRMiUdQeUs4v6ikM0fAsvhIgNh o02Ebre7xfPk4OenUJ6DGnSzGiB19DWzrcbwDl5GNsADsSKJTT8BE5uXwL/H+xCPIG2O WvUhhJ76BGfMh/D97LP7C/Ra444yuYeqFFih4zz1PXeDFIRUcWW9o0PwbOHSH01TT7+J rwog== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@cmpxchg-org.20150623.gappssmtp.com header.s=20150623 header.b="zA5A/pRf"; 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 s10si1217650ejb.154.2020.12.15.09.21.47; Tue, 15 Dec 2020 09:22:11 -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="zA5A/pRf"; 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 S1730138AbgLORR3 (ORCPT + 99 others); Tue, 15 Dec 2020 12:17:29 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40114 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729028AbgLORR3 (ORCPT ); Tue, 15 Dec 2020 12:17:29 -0500 Received: from mail-ej1-x643.google.com (mail-ej1-x643.google.com [IPv6:2a00:1450:4864:20::643]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 47A07C06179C for ; Tue, 15 Dec 2020 09:16:48 -0800 (PST) Received: by mail-ej1-x643.google.com with SMTP id g20so28830198ejb.1 for ; Tue, 15 Dec 2020 09:16:48 -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=yKB5P3mmMeccCVq/i2dQ6a1JB3M5e9Un7Ow5i/UnWnM=; b=zA5A/pRfIGe07vij4DySDUNXt3hgH73LPDdRgKaBBAACVFoNgxY22zOM7GP3MmMhYB 2FQnEUV0TsjZkJ3s4aWTOvRVinmxuDRMe7n7ShuAoxTviyZUA6qf218W7cq3WzXeQIfF TDbPmUP7swZqJXRGQ+LJX3ygthciPd9sbzqcF+q6PgW5PhMAo+36mjNAb+EO1t0jhUdy eMqS18FNCvjazQYxVQ0DEtmAqRe/6zoEUN22fLXP1oWbxT4kzEUnaJKzePjcYmgoDHyu PA9wSgVvbHJi720EjncVezvahEqjjBnRT6GCDHFkG9uMWoIu8KzrwLdbhqBx4iFYv+/s pD4Q== 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=yKB5P3mmMeccCVq/i2dQ6a1JB3M5e9Un7Ow5i/UnWnM=; b=Ulr+CAkHp+bVFth1n397gp+XaUOmNPfSj4rsnq0b2awGOIMp3XcKUbUccwQlOCMaSx zse+I+RdtycuQ0rqR4YyRcwN5jPXC974C0qoxqO2GeCGFQLtiUlZjTx0HqUB4YS8EzT+ jbbLgAv2NVl15gB+ORVgYfX+LQ4XnBXtwWGdXEYP+CqiwEbDCXDUxRtcCRZwRSP3w1RT cXWwXfgXcXZqr75G1aa+OM7whfyE6+8q1Lj4M/yE76bim0A2jW6XLLwuxjnNttXCkn5J 3Y9sjkfPQGIfQvQalOOKtjJbAhMHOxURrtZ5OSlQV0E690LfPKcWLgA9roLDOOqrNuEZ S9YA== X-Gm-Message-State: AOAM533VJ9bXbhNKbEZhGPBmV7zFei24NFagbsdMUOn5zgGk9LqxBsTo if1iyogZi9x4RDA23iujtPoU3g== X-Received: by 2002:a17:906:a181:: with SMTP id s1mr14149482ejy.60.1608052607054; Tue, 15 Dec 2020 09:16:47 -0800 (PST) Received: from localhost ([2620:10d:c093:400::5:d6dd]) by smtp.gmail.com with ESMTPSA id z24sm18899199edr.9.2020.12.15.09.16.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Dec 2020 09:16:46 -0800 (PST) Date: Tue, 15 Dec 2020 18:14:39 +0100 From: Johannes Weiner To: Yang Shi Cc: guro@fb.com, ktkhai@virtuozzo.com, shakeelb@google.com, david@fromorbit.com, mhocko@suse.com, akpm@linux-foundation.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [v2 PATCH 3/9] mm: vmscan: guarantee shrinker_slab_memcg() sees valid shrinker_maps for online memcg Message-ID: <20201215171439.GC385334@cmpxchg.org> References: <20201214223722.232537-1-shy828301@gmail.com> <20201214223722.232537-4-shy828301@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201214223722.232537-4-shy828301@gmail.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Dec 14, 2020 at 02:37:16PM -0800, Yang Shi wrote: > The shrink_slab_memcg() races with mem_cgroup_css_online(). A visibility of CSS_ONLINE flag > in shrink_slab_memcg()->mem_cgroup_online() does not guarantee that we will see > memcg->nodeinfo[nid]->shrinker_maps != NULL. This may occur because of processor reordering > on !x86. > > This seems like the below case: > > CPU A CPU B > store shrinker_map load CSS_ONLINE > store CSS_ONLINE load shrinker_map But we have a separate check on shrinker_maps, so it doesn't matter that it isn't guaranteed, no? The only downside I can see is when CSS_ONLINE isn't visible yet and we bail even though we'd be ready to shrink. Although it's probably unlikely that there would be any objects allocated already... Can somebody remind me why we check mem_cgroup_online() at all? If shrinker_map is set, we can shrink: .css_alloc is guaranteed to be complete, and by using RCU for the shrinker_map pointer, the map is also guaranteed to be initialized. There is nothing else happening during onlining that you may depend on. If shrinker_map isn't set, we cannot iterate the bitmap. It does not really matter whether CSS_ONLINE is reordered and visible already. Agreed with Dave: if we need that synchronization around onlining, it needs to happen inside the cgroup core. But I wouldn't add that until somebody actually required it.