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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id A100BC001B1 for ; Fri, 23 Jun 2023 06:29:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 085708D0002; Fri, 23 Jun 2023 02:29:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 033028D0001; Fri, 23 Jun 2023 02:29:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E3D2F8D0002; Fri, 23 Jun 2023 02:29:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id D37D28D0001 for ; Fri, 23 Jun 2023 02:29:46 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 825DB120D0B for ; Fri, 23 Jun 2023 06:29:46 +0000 (UTC) X-FDA: 80933036772.07.56D3443 Received: from mail-pl1-f175.google.com (mail-pl1-f175.google.com [209.85.214.175]) by imf05.hostedemail.com (Postfix) with ESMTP id 8CD51100009 for ; Fri, 23 Jun 2023 06:29:44 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=fromorbit-com.20221208.gappssmtp.com header.s=20221208 header.b=VCN1cKAz; spf=pass (imf05.hostedemail.com: domain of david@fromorbit.com designates 209.85.214.175 as permitted sender) smtp.mailfrom=david@fromorbit.com; dmarc=pass (policy=quarantine) header.from=fromorbit.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1687501784; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=zCEqJX5mm9cbUE56OVCDucRVQniQh/jh7QjO1tCYRyw=; b=RrvVJMiJChSjjNG0Tfkp3zttTvGtHPdcdhv7Vispo46DPNJ4KPOD+ee6+HP2YWiStjk62T tib65yPfKTl2i/4P4B6goTUxA4GnC1bGW8Z487xwWMiz+FIvVreEtVNiQakcrTpzbqEZSm 9h7hfi8odGoIHTbAyu27EOs1zZ1HVsA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1687501784; a=rsa-sha256; cv=none; b=AKA6cdqRVA5QCkpNUo1DoaDyOLUNtnR8P9HKFQyF0uoIWYHr5OCNV9GZQuVL0WeF1pQl4Z 5F3owa3+KpL2P2Fpl1CI2ASgNufjdz0ncJK0iiJdLZ7VdWvXacCBJ6PfjPyRdY7j6jGrHb 8eZBtt8OX2L6M36ZVl2qoXBo0jlNggM= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=fromorbit-com.20221208.gappssmtp.com header.s=20221208 header.b=VCN1cKAz; spf=pass (imf05.hostedemail.com: domain of david@fromorbit.com designates 209.85.214.175 as permitted sender) smtp.mailfrom=david@fromorbit.com; dmarc=pass (policy=quarantine) header.from=fromorbit.com Received: by mail-pl1-f175.google.com with SMTP id d9443c01a7336-1b5452b77b4so2080335ad.3 for ; Thu, 22 Jun 2023 23:29:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fromorbit-com.20221208.gappssmtp.com; s=20221208; t=1687501783; x=1690093783; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=zCEqJX5mm9cbUE56OVCDucRVQniQh/jh7QjO1tCYRyw=; b=VCN1cKAzYZWGpOm/hUHuPZp8plVnErZlG9G0OlFzhPpXaNGHYvVufkX79JUDsPqJVj SxdYAM9A9ivCYhtFxc3SyvMZr6s5SlnDngyF1CSlxpEdm/HUuOSGwHgmJomuuYgedrRX aqax0M2Dw9QUTGwitN8bpL0qLseKhs7EVUc6lepS488qyivLAQHSFGtevNE0LyqUhWPi NKkNR95/QZWn2OoaLsjXJllgmMFsp0mHDlbo5o60jR1YeUkdYXlMSdAiD7/jZsXdB48G reDdzoxXO5mM4WdQ8i9rMsSwtC5huiBFlnlMXvIXzYTlsiTrC5P7Z8F16npWgNIfnf8B ShDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687501783; x=1690093783; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=zCEqJX5mm9cbUE56OVCDucRVQniQh/jh7QjO1tCYRyw=; b=G7pk0q/d479rI4ImhHZXVEmoxM5RvgWL2qysT8bf6DmuxyI/oIw3yMQkVlDCU3ft03 NjGA4jcS7hUn9ZFIhOV8/5ajIYf+SPYAhfiAvXbCgYD09BYjpbJ1ok15AVwjLgIfP1wi HOymVoY/6U0xkOzwJ8ZlZ+jPrhyKZCpVr93y0YplZgQwsrk+h7XPqCwwTZVMVxEBc5IG AyAPJqUceAjCu/ryuia5dt0U7rH27xuoc/k7bki9yTu96mb573lQfHjrcTTest2zWsaR rUSyGgnCDXJExpxnTtqjerA6HKc1jDmgdoCefLxlMLXii9gv9zhBCtTMltE7FuoOWARn QYDg== X-Gm-Message-State: AC+VfDxFq+QzfbTeRVKSJTT8IIX+vO1FexCeDOkuf+hW+rnfJw7U1QFo PdFeFIHYzKw155oxpPgGyz87oA== X-Google-Smtp-Source: ACHHUZ6xCu/M/0AOwG5LVLb8OX3DoTsqyFTeplRrHsUG1u2SLkBGduWAm9ZrSI41Zhf0Zeq1UunMJA== X-Received: by 2002:a17:902:8214:b0:1aa:d971:4623 with SMTP id x20-20020a170902821400b001aad9714623mr18870991pln.38.1687501783228; Thu, 22 Jun 2023 23:29:43 -0700 (PDT) Received: from dread.disaster.area (pa49-180-13-202.pa.nsw.optusnet.com.au. [49.180.13.202]) by smtp.gmail.com with ESMTPSA id x5-20020a1709027c0500b001b246dcffb7sm6311389pll.300.2023.06.22.23.29.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Jun 2023 23:29:42 -0700 (PDT) Received: from dave by dread.disaster.area with local (Exim 4.96) (envelope-from ) id 1qCaId-00F8x8-0s; Fri, 23 Jun 2023 16:29:39 +1000 Date: Fri, 23 Jun 2023 16:29:39 +1000 From: Dave Chinner To: Vlastimil Babka Cc: Qi Zheng , akpm@linux-foundation.org, tkhai@ya.ru, roman.gushchin@linux.dev, djwong@kernel.org, brauner@kernel.org, paulmck@kernel.org, tytso@mit.edu, linux-kernel@vger.kernel.org, linux-mm@kvack.org, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-arm-msm@vger.kernel.org, dm-devel@redhat.com, linux-raid@vger.kernel.org, linux-bcache@vger.kernel.org, virtualization@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, linux-nfs@vger.kernel.org, linux-xfs@vger.kernel.org, linux-btrfs@vger.kernel.org Subject: Re: [PATCH 24/29] mm: vmscan: make global slab shrink lockless Message-ID: References: <20230622085335.77010-1-zhengqi.arch@bytedance.com> <20230622085335.77010-25-zhengqi.arch@bytedance.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 8CD51100009 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: bxygchgyhmw6c567x3oe53o5qdq3z1tn X-HE-Tag: 1687501784-715316 X-HE-Meta: U2FsdGVkX18i3h/Aw5O1TJFWGUBwn2wQBqAUpCs+UgZclpu4DhnPAxr1WO8iqq9/Z6Q/lzsNVfYoBfWo/ugonI+PLGBja82rmrIzhdfAYEhLUNZkL1eLiOuau8jUFF/rq3VYVWgRsVosIwjrksoCSkQdMyjIghQNBeuXpxOzKOmNZTGtylhE6zmrYr5LjUlvQAQVWODJCh3ysLPFNI3ue4s4T2hjxNPy+V87v9vSM3NU51XovAzHPm8IrcboStgHoVPFnbJ1lNJKrvtvcrN47CsdUD1KwvzJqrMlrkFRwKycCH0SmF86oFnkw/F4hvSTjnL0wanzpPcKFiEorM2TorAr/DmnHj8cFHG+22sN33Sdz+0oggLJs+7cxvEeFzDk7/no1j0YhYLEE6CKghrFcUyAlC2sCzHwKEG0h+tPHo9fy7vd7NoxkwYdEWPGNNemapTqXZLZT4u5+OxSxGzYUAxFAcOtkMFMp8w/gGHYPVyfpzmCvli6rYlUDROsbZrkhxqh+x4PiU7sP6yBNIV8hqlIpY6rgqERKDFUfAw2ZWSzINWaXi0p8QotcORUx1H029KRqNtoNtlDEDO7jzg68UgCf2yKTf/UD+BaHwML+LLBjysUZSFWyyiw6WwUVWto47fzVr+i/cKMLJekcljdWP1jlFa+WzaJaVEtOasRW5MsKykSL245uwn0HWCGCosSvf05wM6TLaaOtV3HlgtyhSeqQezgmpJ9B8JyyVPsAQu/dCjmaQ+fbeMjp782CYSmbW3aRbKH7lzdb35ngTX/M3pEkRO7eRUABJMAgboaqYmx5qGVVAQPFQgUGyd7rCxUwl7i9LLYHEbkn1CtBowCOx0vD5JZTxywexSugBO9mBm6xQz3jXnRq9BtQr5IQcFtQRa0nPfKM4U+Hqmp2o7Q8z2SN1VDMIKXfzyLeVOcDc4d+9614FMNCSRy/0AeBxd0kqI9txWTHCWO9Nfwcvg btKHY189 7bZGGUcCr4bPNOBwnikfe0IzB0kIvNCUksaOQpgYYXEyye2L2cph9RljfXn7wdSfaOn0C04ugpeWnrK2cqN7hQufed+ZGEr9cOYCpFevopjUlbelDHKch3mCZPzcCgeuxMbUHJruyQcWj5JwYDQ9J+rSCV+EOR614aGMbnhrqkvcV4BtJsNOZf2RG78cmJkh/C+GwFDRvL7aNSJiGL5QUb8FGJs+37u9o/Uv+rE4C3XJyFcBihk0Hs+XZwGifg2e3ae4U6r6t95sW/Eg5Gg+O+d57fNJIDXJYi9heMFZ3GNN+dM3C8L27bSvTnGBiy1wbTNIQCh+mdX3LmMZ1U3XIuTdbMpfKS69wvAhMpDBAGg9jVvki8QPuT99tzEwuNnBEGI8JjhzyofqOJgdtzftRh0kihM830dHaLbPNeOKmjDdmRm+wD2aGVWayrzNtssjJpVfS 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 Thu, Jun 22, 2023 at 05:12:02PM +0200, Vlastimil Babka wrote: > On 6/22/23 10:53, Qi Zheng wrote: > > @@ -1067,33 +1068,27 @@ static unsigned long shrink_slab(gfp_t gfp_mask, int nid, > > if (!mem_cgroup_disabled() && !mem_cgroup_is_root(memcg)) > > return shrink_slab_memcg(gfp_mask, nid, memcg, priority); > > > > - if (!down_read_trylock(&shrinker_rwsem)) > > - goto out; > > - > > - list_for_each_entry(shrinker, &shrinker_list, list) { > > + rcu_read_lock(); > > + list_for_each_entry_rcu(shrinker, &shrinker_list, list) { > > struct shrink_control sc = { > > .gfp_mask = gfp_mask, > > .nid = nid, > > .memcg = memcg, > > }; > > > > + if (!shrinker_try_get(shrinker)) > > + continue; > > + rcu_read_unlock(); > > I don't think you can do this unlock? > > > + > > ret = do_shrink_slab(&sc, shrinker, priority); > > if (ret == SHRINK_EMPTY) > > ret = 0; > > freed += ret; > > - /* > > - * Bail out if someone want to register a new shrinker to > > - * prevent the registration from being stalled for long periods > > - * by parallel ongoing shrinking. > > - */ > > - if (rwsem_is_contended(&shrinker_rwsem)) { > > - freed = freed ? : 1; > > - break; > > - } > > - } > > > > - up_read(&shrinker_rwsem); > > -out: > > + rcu_read_lock(); > > That new rcu_read_lock() won't help AFAIK, the whole > list_for_each_entry_rcu() needs to be under the single rcu_read_lock() to be > safe. Yeah, that's the pattern we've been taught and the one we can look at and immediately say "this is safe". This is a different pattern, as has been explained bi Qi, and I think it *might* be safe. *However.* Right now I don't have time to go through a novel RCU list iteration pattern it one step at to determine the correctness of the algorithm. I'm mostly worried about list manipulations that can occur outside rcu_read_lock() section bleeding into the RCU critical section because rcu_read_lock() by itself is not a memory barrier. Maybe Paul has seen this pattern often enough he could simply tell us what conditions it is safe in. But for me to work that out from first principles? I just don't have the time to do that right now. > IIUC this is why Dave in [4] suggests unifying shrink_slab() with > shrink_slab_memcg(), as the latter doesn't iterate the list but uses IDR. Yes, I suggested the IDR route because radix tree lookups under RCU with reference counted objects are a known safe pattern that we can easily confirm is correct or not. Hence I suggested the unification + IDR route because it makes the life of reviewers so, so much easier... Cheers, Dave. -- Dave Chinner david@fromorbit.com