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 2FDE9E936EC for ; Wed, 4 Oct 2023 23:10:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 500988D00B1; Wed, 4 Oct 2023 19:10:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4B07B8D0002; Wed, 4 Oct 2023 19:10:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 350C38D00B1; Wed, 4 Oct 2023 19:10:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 235838D0002 for ; Wed, 4 Oct 2023 19:10:14 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id D66E940134 for ; Wed, 4 Oct 2023 23:10:13 +0000 (UTC) X-FDA: 81309324306.10.836F9C4 Received: from mail-pf1-f179.google.com (mail-pf1-f179.google.com [209.85.210.179]) by imf12.hostedemail.com (Postfix) with ESMTP id CC31140011 for ; Wed, 4 Oct 2023 23:10:11 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=fromorbit-com.20230601.gappssmtp.com header.s=20230601 header.b=kgCHzL9a; spf=pass (imf12.hostedemail.com: domain of david@fromorbit.com designates 209.85.210.179 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=1696461011; 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=pBCvMKFa+vcZnG26/JeWxeoSgocrNcnNb84l5SDtiC0=; b=cHbjxcjMYjxf+SBL5e4M1XeEdKtM0wAXtSmGG3Gjqt62NQz5gSlYjdbsCAN8jaNr4QIfBW whykpv8bvhk6VkPZMW16iiHnaVQqrX4b19MvCtc023yupU+V9RqHOpIK4i7YZLqgs/5VF3 O5LGDWsmbVuE9jD8ia6ZHgql/ljeyD8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1696461011; a=rsa-sha256; cv=none; b=ydGwLa7Rh5nurfLrg6NxoWFYBcsSkKRVLgVFjDwRThXHCuNHO0Jmj9uV5hmF6xUfZ8/cFz dym2SN8E0it5suimG/kTOATALGQxfwU0fZ8AB1ZE9qJMMUrwNXjHA99Mormy1zpaXQUj/I iUOyrtT9vOvq9xEZF+I4tCO37Jn3qYU= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=fromorbit-com.20230601.gappssmtp.com header.s=20230601 header.b=kgCHzL9a; spf=pass (imf12.hostedemail.com: domain of david@fromorbit.com designates 209.85.210.179 as permitted sender) smtp.mailfrom=david@fromorbit.com; dmarc=pass (policy=quarantine) header.from=fromorbit.com Received: by mail-pf1-f179.google.com with SMTP id d2e1a72fcca58-690bd8f89baso272135b3a.2 for ; Wed, 04 Oct 2023 16:10:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fromorbit-com.20230601.gappssmtp.com; s=20230601; t=1696461010; x=1697065810; darn=kvack.org; 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=pBCvMKFa+vcZnG26/JeWxeoSgocrNcnNb84l5SDtiC0=; b=kgCHzL9auICBWsmP0FqRhSIa0VYPrvOShDPnHmKOVH2mGovdQbtOxo23omd0h4T3ON 0ce5AKvTvochMQyc7I8X/wPSf/n85wee2KbcQW8GciwXe1q37ClOiZnFcXtdOmpjYQOW uLck4pYhYSRmxIa0J1XC3p45wPEqCQFR0FNlUVvvx4vcLh5ODxRrAtiWfY2tbB5603eg uUFoMkTQdDb5BZhIg5jQwYPY3v5MkBDFUDo906jWnGdnG3l/o1F67tbClO3iVjEdMvLi ct1nq+DIwH4nFw/B53Zsd/TBJIvFkCto6UkTJDtPZkGh340gBFCEXdcPI2jupD4zfYn8 i5Tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696461010; x=1697065810; 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=pBCvMKFa+vcZnG26/JeWxeoSgocrNcnNb84l5SDtiC0=; b=h8JnZ+4t7XTFLsshWE2BtC6+S8mYH8MIofRnnvy0bZ8TfGeA163p6Z9wNf/fMrkR87 D9Ti59YxnPJDLzAuKsLvODz5O6AqgWuiQJz5CJ5gRWTl6D2DqORqP4nslDuWz6YruTA8 OkbKdxXchy0HP9Xn4opp0DItbHk3m1RF3Y0mJ/MDGUkVlF/syvWFZRlLzBqNUz5Vn8It wsxjUXE/+wIN+xVUMOXcdvvezbXZT/iqHXbD/Dmie9hnnVPoYa+bmebel4xFgbfkYhNs nj+ZRa+aY29WxtCXZS73l9VLrMC38QthcDfnZoZHhEn8PyV4a7g5xo6rSOQFXewpPQeD H2ZA== X-Gm-Message-State: AOJu0YzgjJgwSYrOmw97NEftDoGH3RFrS7pZydtlswY5Hy6HCJA2JROu 9BvZTKCEjazJlLOvikk4LPIUAQ== X-Google-Smtp-Source: AGHT+IEzCkW3N7WbBiXE2690U1CrRQ58ztSV2yenmMp5uTGEVYjAPVvffGppyu1YjwxFATJTBrrj0A== X-Received: by 2002:a05:6a20:9698:b0:15d:624c:6e43 with SMTP id hp24-20020a056a20969800b0015d624c6e43mr3049725pzc.3.1696461010435; Wed, 04 Oct 2023 16:10:10 -0700 (PDT) Received: from dread.disaster.area (pa49-180-20-59.pa.nsw.optusnet.com.au. [49.180.20.59]) by smtp.gmail.com with ESMTPSA id x3-20020a170902ea8300b001bdb8c0b578sm100725plb.192.2023.10.04.16.10.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Oct 2023 16:10:08 -0700 (PDT) Received: from dave by dread.disaster.area with local (Exim 4.96) (envelope-from ) id 1qoB0H-009XMo-3D; Thu, 05 Oct 2023 10:10:06 +1100 Date: Thu, 5 Oct 2023 10:10:05 +1100 From: Dave Chinner To: Hugh Dickins Cc: Andrew Morton , Tim Chen , Dave Chinner , "Darrick J. Wong" , Christian Brauner , Carlos Maiolino , Chuck Lever , Jan Kara , Matthew Wilcox , Johannes Weiner , Axel Rasmussen , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 8/8] shmem,percpu_counter: add _limited_add(fbc, limit, amount) Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: CC31140011 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: s3dany6q8w1ua58cou435ykq3hrf4pkw X-HE-Tag: 1696461011-132435 X-HE-Meta: U2FsdGVkX1+KvtiPv4zdG5FMZM2xxazIuX0HZfyibU/+23mgRcyr5m3yBdTSVJjg0nNHBabG3FnboIcLBghGwdOWJKYxxP6fbHCMwZBimHG91z7cStAx4YR1iU+9hoT8JITr2eOxb/7yyM5gppnRRdi+52jTRzyZFWuax5hKZOOeWeiK4Wh5jGeq4mxaEj6LxCscsnUjiGw76+91V/PoNk490aJ7r2p9f7I/2CSf4OZwImUhNq0pa++EDbADokwtOkEfMyX9qPrBz0XFA8qUkjv2VcNs3tZ4OJ+vxlUpmIags8DnCf4IN+A/P209aJ86IHSjqFgu8W+kD2Q6CaNA/iUYmSB3oCw5XYI2EV87Tw27x7yEly+F/X3DyPUQpAV6GKPIwVhs50XEfbZ+yunjR1cipJKe0VztfIwxylzpeT3AGP5Uq2pTjbHsiaGzYaxvthYwjDLHXjJRX8GS7jPCpKI+M+B6xoOdTbd8mFq5By/W0yLpkVb2NS7rbdCPUs9lCbkXe+oulyc/TEtrJkmQQKtiXkYjvvO1fK4DXsJeF4tUEuvaimNW89p/fP3KhFol2mW6oiq0PLQWEBMJjRYXzM3XmfOXEU5CNSBM9vU8lSMKDaxKY4P5qLWoWhoukb43TAEX6h0+URa+uL18WUdQOVO3EvdGsz2w1cDASX+qTv9kxaz+LYsOYaXFCsEt9GPh73oOZd4pjUSC7pX2+JD7ohgqZEJYlURT0BWaEZDTisNvdQh2KSXZHYCkZ21Z7Llx9HqSpCpMcN/l2Ug4yDeoYUBeeum0nyZYo5nI9rprX8HMpXsn9wGww/TyimtJNmixuHKdNI20NIeJRSIYu+yIM22GLZ6bjN53KLA7vQJQ9rnKtlu7OYIhusZCcODDlLYZgcciSBAyfZEXR5PAwEuHYxQYsXAAyQcDmXMn54a037az+WbTuVK3nHYjSOk5/oWMpehZ+XcouSR2q+ZI9K+ +WJBQnN9 GsaiUCn4E97ikIpdsXvINFj83SU3sajFpHmR7aZzS4lZODft1gEJq0n5Z/Pl1EA2/qgjU3lRNjRWIIIRlm1wR73XoziSyQt+azGQ+4cBYC36y/fe9Qg1SWcC5z+py+SMRP94bm87ver3dSBoSkZbKdyeq4edcSeGlUHzUszxC6lZDGtUq776OR3qMVD1IE35i6S/s8EecKY28yixgAQYmaIzeD1agDRqCz7MV5yghO1e00iPUNJ59H4LU+nyMYrQbVj/rvdVN8Xbhw0lW6w/ZG6c2uErAIzhCdWWjbge2TRPcQsl1GZPiBthQEzHx+EkY+1xUn7KxaEOPiRrRmEx/1b4rMoYIfF5W9WkMfDTV3/NANbYn3QrSeoyfM6HRb75Z/QBRxNX8/uJ8H6phjsnbaHEHqKk2fP/SwALR1SrLdDOzet0N+BhvPNOoEOtC0eIWfH7Q67CFZnI0qczy2jyIadi5fX2F/VgV6J+KeksHvX1pezABuWTK1+fvcQXppM3gJmKS9hxXhhvubLp/xtPmOkm03QTnWki/xBs8zodFxeG5WLDrVd4UFuHiN0+iW1SNDa5RE7YWmUChzrmA2JJt/uQz/Q+9y94v5v2lNwEF/8qUBLUTvnbITs4cGg== 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 Fri, Sep 29, 2023 at 08:42:45PM -0700, Hugh Dickins wrote: > Percpu counter's compare and add are separate functions: without locking > around them (which would defeat their purpose), it has been possible to > overflow the intended limit. Imagine all the other CPUs fallocating > tmpfs huge pages to the limit, in between this CPU's compare and its add. > > I have not seen reports of that happening; but tmpfs's recent addition > of dquot_alloc_block_nodirty() in between the compare and the add makes > it even more likely, and I'd be uncomfortable to leave it unfixed. > > Introduce percpu_counter_limited_add(fbc, limit, amount) to prevent it. > > I believe this implementation is correct, and slightly more efficient > than the combination of compare and add (taking the lock once rather > than twice when nearing full - the last 128MiB of a tmpfs volume on a > machine with 128 CPUs and 4KiB pages); but it does beg for a better > design - when nearing full, there is no new batching, but the costly > percpu counter sum across CPUs still has to be done, while locked. > > Follow __percpu_counter_sum()'s example, including cpu_dying_mask as > well as cpu_online_mask: but shouldn't __percpu_counter_compare() and > __percpu_counter_limited_add() then be adding a num_dying_cpus() to > num_online_cpus(), when they calculate the maximum which could be held > across CPUs? But the times when it matters would be vanishingly rare. > > Signed-off-by: Hugh Dickins > Cc: Tim Chen > Cc: Dave Chinner > Cc: Darrick J. Wong > --- > Tim, Dave, Darrick: I didn't want to waste your time on patches 1-7, > which are just internal to shmem, and do not affect this patch (which > applies to v6.6-rc and linux-next as is): but want to run this by you. Hmmmm. IIUC, this only works for addition that approaches the limit from below? So if we are approaching the limit from above (i.e. add of a negative amount, limit is zero) then this code doesn't work the same as the open-coded compare+add operation would? Hence I think this looks like a "add if result is less than" operation, which is distinct from then "add if result is greater than" operation that we use this same pattern for in XFS and ext4. Perhaps a better name is in order? I'm also not a great fan of having two similar-but-not-quite-the-same implementations for the two comparisons, but unless we decide to convert the XFs slow path to this it doesn't matter that much at the moment.... Implementation seems OK at a quick glance, though. Cheers, Dave. -- Dave Chinner david@fromorbit.com