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 359F3E7C4D0 for ; Wed, 4 Oct 2023 15:32:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 749858D0078; Wed, 4 Oct 2023 11:32:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6F96B8D0027; Wed, 4 Oct 2023 11:32:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 59A1D8D0078; Wed, 4 Oct 2023 11:32:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 47BEC8D0027 for ; Wed, 4 Oct 2023 11:32:37 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 172AE1A02BC for ; Wed, 4 Oct 2023 15:32:37 +0000 (UTC) X-FDA: 81308171154.18.DAAB05C Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf16.hostedemail.com (Postfix) with ESMTP id 85F9A18002C for ; Wed, 4 Oct 2023 15:32:34 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=PWNpNgIS; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b="/a/QgrmL"; dmarc=none; spf=pass (imf16.hostedemail.com: domain of jack@suse.cz designates 195.135.220.29 as permitted sender) smtp.mailfrom=jack@suse.cz ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1696433555; 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=E7rPN2B6EKTGm9PeH9o/j7eO/9ZZxPutpFnqoFCKJ3c=; b=pd//rXEbPxKmqabfxPnyI46X3gXjiKbsk2E604fjGgpYvvsuCP1NgQnoKUrpYLiCCHnmyu irsSiGPYhHCBsWj67wAkHwekRn4DQAz8hxv49ylw/rYf5xm9xXlJn3a1n72t/heEey2bPg MccollbyySOFCIB7njxLBufzGsxQpgM= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=PWNpNgIS; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b="/a/QgrmL"; dmarc=none; spf=pass (imf16.hostedemail.com: domain of jack@suse.cz designates 195.135.220.29 as permitted sender) smtp.mailfrom=jack@suse.cz ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1696433555; a=rsa-sha256; cv=none; b=D/mnkNOYHf2U9YM+gzChcZ08Q1nKNaHroniscu9SHzR6BK46vqR37kYPdrGJ7mBmcGuVHZ XQpCIFCpFQEom1KxzQw25JQ1TIooU9rAuWBBkVsP0QQDTrT8zEmQUf+rk94GhERzaL3Be4 tUkWzVT+9iMTLFSIaBD6njM/4Q6mBoM= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 331071F88D; Wed, 4 Oct 2023 15:32:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1696433552; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=E7rPN2B6EKTGm9PeH9o/j7eO/9ZZxPutpFnqoFCKJ3c=; b=PWNpNgIS0ejpZaWNfc0RvB2fG2vV8czGrqfLFnVTWcWRavWyJ4QgAKcXC6NTyqjpPPXLIR ctspLD8VBoyOKiAiK+atQY00RcObsQ/ufJFWQxDaExXcReriBuPYwsegsPUtk0sKuldjvw NaontetfPZBnTsqhYoaH2uSIFUYt+XI= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1696433552; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=E7rPN2B6EKTGm9PeH9o/j7eO/9ZZxPutpFnqoFCKJ3c=; b=/a/QgrmLqwF9uzFD93sACvd/cUymLm7NK62R1MpzNFNbQH5uu3qguAu7sOD1484Ey2FveJ RH6ttpyXbHMa7yDw== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 2219813A2E; Wed, 4 Oct 2023 15:32:32 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id jbpJCJCFHWUhIAAAMHmgww (envelope-from ); Wed, 04 Oct 2023 15:32:32 +0000 Received: by quack3.suse.cz (Postfix, from userid 1000) id AA6E8A07CC; Wed, 4 Oct 2023 17:32:31 +0200 (CEST) Date: Wed, 4 Oct 2023 17:32:31 +0200 From: Jan Kara 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: <20231004153231.gj5ds6r2tdjwjdwd@quack3> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 85F9A18002C X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: d1ayqoedbzx5iib6996z6tf1kxeznd6s X-HE-Tag: 1696433554-44436 X-HE-Meta: U2FsdGVkX19KdW/F5qEhy1kffv2h17G76atjZcTjFnGCInmSMuiPwWZTSqkQkApRxymzXH1/XkyD4q4RPH3+Olt6S7cP6M6UUYEBtlFUciFsnENbpI4b3Q5iQqsGcd8tPSpGuhzAD/K8MZtZ8+0dLjkUwTIeh2MSD895Lu4QxTLc0p/TZMaGgct5TPuHnUq+ChLhj0W8zUcGgEDN82dAK9ciA1APyaN+/WR7222EZh8iQR10HyhtMM8T3JlaAvPlbFuGkbI/vGbdYGZ5I4NBQwNQ3C4XyMCSWoJluteMlKFNtqP1FId2+zYWum8ccY/V7h91mB+UfUKsCHJuDi7dFye436TuKdMbib4g83t58xwiPtFUK1dIDsLzZSskV1MIfakAXtExXZ8FLjHf56NmhGxUqXGvEST8yG24AVz5VqdqI1EX3D6KYufUvesRlV+8omqjxAE3JlzEfXNRyxF/DbQvEMxxWR09ZFacGhqbu4zN/8idu1EUKlR/RgerfL3qjNbgBC2pZSk7m79e6SVBZAvakhiOQ3xhatMNBLjm8iJWpGyS/au6W/mAQpQ6MMaNATTWDnRWVwmpM4uO/89GClNAzs85l5PKtWls7vD1mgxTrie5lRrzSLMHzxg1plkfXSMZTN/0bW4/UybmOEY9CfjvliTLTNjQcciC4/Zsl2zEPJm5luNNSL8BxFgNP9K2eaEO5gmet3mvgcPiyKb5cBFVb8Ibt96vLallrTXQ+9xh1RD6ro84DoV0uM64Sp5P4xdJpDYI+5PDAvP/7SOAnekvHInhBVqyWDBe2F7uMvzNGd2LMQi2NJez1w+mgdvNe0GxbgNnej/iMUozeyr+ymIlFsnLuY4kgpCou175gIU7Rv3xTRZeXTvRSS07Ja2JIFcqQ2hZ5SZlYbN9qixBvB6dM2+ssQKm31NPog+tpZ+8flsgaAvSpvjeB0vx0kCZEsnLTn0JNofP55zCeSq xGjPWnr/ FDFSMeg31ygZNMa4jPTxynKwDNw6vduPFbVBWcshzrYYp0A5pJu/Gr5dWQ0l8ehX63L9WgCcPESnnsNbLtY8xlQt/+RouT/u3z9+my4/tDh2xkz3ytx9xxd4tqSdtHWm//PWXxejLE4Bujoc7nayOAAz03xamYa2Ro9Dj/p3il+sEy2XqJ0xtodhhpnCd9E5c1BKhwWbD6KTJyupHH7ijLvUET9qgPLUk2HD7kLuSYFwWYoIQs9S7pfdr1OziPJjS79BwAz+NsvbO+7MGgRu09q6XxRHZvBLYz7pzEtl8/4Tky11Pedl37E9JzbwemeUgeUcbe17nQgjZ41ux/Z982Ek4FLjrajUrdtPwSJFl7K9hLHQZV6i8b09xirLdXkpyvM3oxv5qsWu/kEN9GSrE2DmoV2ZbvWv1NNBCfIi6as7ye0U= 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 29-09-23 20:42:45, 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 Looks good to me. Feel free to add: Reviewed-by: Jan Kara Honza -- Jan Kara SUSE Labs, CR