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 EBFD8C2D0CD for ; Thu, 15 May 2025 08:41:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AFB9A6B00C2; Thu, 15 May 2025 04:41:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AAA496B00C3; Thu, 15 May 2025 04:41:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 925196B00C5; Thu, 15 May 2025 04:41:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 7270E6B00C2 for ; Thu, 15 May 2025 04:41:44 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id A2B72E3208 for ; Thu, 15 May 2025 08:41:44 +0000 (UTC) X-FDA: 83444498928.03.410D6F2 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf10.hostedemail.com (Postfix) with ESMTP id DEB37C000F for ; Thu, 15 May 2025 08:41:41 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=cNPkKacg; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=0jZJW7Ko; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b="rfoEs13/"; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=sqKh1Lqk; spf=pass (imf10.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.130 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1747298502; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=hds4IGkoceQaeUi/wJBpSLkCnk5XKktfUCvS0xFhBvI=; b=gWQNVP6UNq3IdAMMYXi0mtBUZkX3gu53DyKu3WRgft7BlvYBtOn0uT4/4+Qwg6zgx448GF iqNqu0c51Y1SpIL5XGftdyyxdLqSakSa3L3ds6wOHLUlz0Bbo6o31pM300vxKWEQYADv0l n1u8OCOLZ7f/d8oGYge7PY02FH8A8V4= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=cNPkKacg; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=0jZJW7Ko; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b="rfoEs13/"; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=sqKh1Lqk; spf=pass (imf10.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.130 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1747298502; a=rsa-sha256; cv=none; b=ygHRYDA38VivlgLq2MQD5km0mfu1A548wtcjX53gyffneLCS78i8G7z+u6MwBiszhzTJtL A2rk7bzbxucZdEIzXnoS3yL7nO6rV10QZHMCLJpB1TZsOltKROvKrvvMF2RRp6q2jkAj9d H9Ov4hqva7/yiH7CPC13N7YNSjYT41I= Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id A8C79211B5; Thu, 15 May 2025 08:41:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1747298499; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=hds4IGkoceQaeUi/wJBpSLkCnk5XKktfUCvS0xFhBvI=; b=cNPkKacgAEltoTCy75IKkvQ8gn9mxFgaCHogP9vwBd4tbvzOT+dXzC9EZJNWYU8vCC4n/Y vNbyP1nVVf4udiu4dtIaFcW8+HLLxZFuvHQBDsbWe+E5HfCDNpYiDE7CqdHva4ZDeazoLR 9pUn+htNTbZ4cSQp64uojLl2RxoTvPg= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1747298499; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=hds4IGkoceQaeUi/wJBpSLkCnk5XKktfUCvS0xFhBvI=; b=0jZJW7KoUXa09MI6NueejmYgX9UqkFlQYSSN1Jzgsun6z2KxJalgt3L4kTE6PFe6kVO5i4 bZguB3Bk+RQ577Cg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1747298497; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=hds4IGkoceQaeUi/wJBpSLkCnk5XKktfUCvS0xFhBvI=; b=rfoEs13/ATXNW3sCjEkaCwybAGskmpNUW+rfPueuikQ9rlDzmjM94YzKRchthxxScYdF6V Qnb9VtArXSBfzY26bWbAOjM6YLPbH5yqRvCksizjKwe174Keej60MFBvn68OKX6yZJ0PrW pz1ISFCV41Tf+mULqY1kxuQNnkVoPss= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1747298497; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=hds4IGkoceQaeUi/wJBpSLkCnk5XKktfUCvS0xFhBvI=; b=sqKh1Lqk1YSrQrfpb4SZEA2EE+mDrNso3Md3R01GDWr4KfSND3iyBqoCl9SaVN8NryVuBK TKI9Lnzu6Wxh50DA== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 9265E137E8; Thu, 15 May 2025 08:41:37 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id FEpuI8GoJWjUPQAAD6G6ig (envelope-from ); Thu, 15 May 2025 08:41:37 +0000 Message-ID: <488fa28f-e778-4ca2-a171-dba32abaab21@suse.cz> Date: Thu, 15 May 2025 10:41:37 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 3/9] slab: sheaf prefilling for guaranteed allocations Content-Language: en-US To: Harry Yoo Cc: Suren Baghdasaryan , "Liam R. Howlett" , Christoph Lameter , David Rientjes , Roman Gushchin , Uladzislau Rezki , linux-mm@kvack.org, linux-kernel@vger.kernel.org, rcu@vger.kernel.org, maple-tree@lists.infradead.org References: <20250425-slub-percpu-caches-v4-0-8a636982b4a4@suse.cz> <20250425-slub-percpu-caches-v4-3-8a636982b4a4@suse.cz> From: Vlastimil Babka In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Action: no action X-Rspamd-Queue-Id: DEB37C000F X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: p65qb8aos9pp3dnfjhox4dbgngjr5jnr X-HE-Tag: 1747298501-32197 X-HE-Meta: U2FsdGVkX18Rpwd5pbseqW3RqXpy4ospy7vxr+NsFBEYSGzKo1Gj+fyAjsIPJKhn5AsEu4THh2tPtTGp82sNfRty4195nq6LNJ5KQKxQ0kHfQSCLnULbaKeqQYZloPUZW73Az1Qf9Tigm5qLsmJyFVCt/lKqw0ATIxpNUes89dbx/ivcH0MrIstUG/5lQ0PjE02puVo5PDAQYLDt4unp+ZZlfIq/ia5HR0BoLjrx2uN7NyTuPbUuultIzuwFpvT1tUncvnyoUZj6ixOFt7y/qPxoTdcHEid9BNhSdRmaYZbLcl/qqM1MqOrAXvmNMmraw/N6AiU7vhHR841bK65HKzofzGKwaF9VkBBa15wJvnNz7PY52RFfjg69HhzO6ZjO8GAznnvKpf5/Hs5Gu+kLYr6vZkmIx7ATGtZEVm6bojT9zwvBBYTTLL7cmcdDL4u5kf3gU6YwlSMhsoo5tMwEWMI0UM97axblIUyZhHOM8XhU5KbsSCO58YMNA84/ZfuTaj+t3Ym3bGUOo2bxVJH2sykIS6DE6uwQVS2PP8xI+1mtXpa8v/nqgK5DkiIdirB1Av4z0R5wfe10NlDw+Jd55mThcbCdeF1Rx75wdXd1KmvCxqC8BhwHHTwzzHV0KZBI2iXhmVzrWU7zF6ifrh9pxtVkQRTYRSx8ZoExcneGxf2tdiE+uQN9Gr3eycbESWwVGfN9iNU9LguhNJmC70bYX3s4m68ugJz0MOiF6cfpPiNrhpdJ+vpCNNzoWeasjadkSfOrJB1WpWTQ5aQoL1zx5JkO4e9Rk/YEiW7BFo31fUMavHrpIl47fjlSX+eYeFzJV0AxLWdP3Wkmnk+4nlqne2TJXovxvYBlI2kB/e948fhB2HZeOFtv0R5BHrC0pb9p0XmSYKaZy31rA1geEoiKB1t8SdiXGjzKp/4NLD85/0EhNW6azs+6q+J/3ic4/U5P02J1bEqDdBuR+BNLL1z FPvWkdfZ jwIg+8eLpB09zSyL6OyQDuOsWZEJ7E05k+3meKA228ywPrFRPpjF3bdlQ4Us7PrWcsj5NJ8p//QCEDmBVh7coCbUubrHZidaxsDa4lgFEIsG2h00fmk7qgjn8lMeWEKBo5j71xyS+rMw4ZR6883cNMkePSNoR+ZBoeqP/nFobYr36eprwoRkGGUucB9QScKmiyL6OMw8WxyrQ/oUdCoXo5Ccl/VjRoiqXE/pgrGQgS4qn3HPHKOGONvcZRts3HnA9f3jX1BWsT187LNEKWGFlHgukDy9T7xVI8i0XNfoMfMzYxaTjmSUj2HxUVHLvqfLNo0xlLzSzxabt9lnQ3AN9QgeanA== 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: List-Subscribe: List-Unsubscribe: On 5/7/25 11:15, Harry Yoo wrote: > On Fri, Apr 25, 2025 at 10:27:23AM +0200, Vlastimil Babka wrote: >> Add functions for efficient guaranteed allocations e.g. in a critical >> section that cannot sleep, when the exact number of allocations is not >> known beforehand, but an upper limit can be calculated. >> >> kmem_cache_prefill_sheaf() returns a sheaf containing at least given >> number of objects. >> >> kmem_cache_alloc_from_sheaf() will allocate an object from the sheaf >> and is guaranteed not to fail until depleted. >> >> kmem_cache_return_sheaf() is for giving the sheaf back to the slab >> allocator after the critical section. This will also attempt to refill >> it to cache's sheaf capacity for better efficiency of sheaves handling, >> but it's not stricly necessary to succeed. >> >> kmem_cache_refill_sheaf() can be used to refill a previously obtained >> sheaf to requested size. If the current size is sufficient, it does >> nothing. If the requested size exceeds cache's sheaf_capacity and the >> sheaf's current capacity, the sheaf will be replaced with a new one, >> hence the indirect pointer parameter. >> >> kmem_cache_sheaf_size() can be used to query the current size. >> >> The implementation supports requesting sizes that exceed cache's >> sheaf_capacity, but it is not efficient - such "oversize" sheaves are >> allocated fresh in kmem_cache_prefill_sheaf() and flushed and freed >> immediately by kmem_cache_return_sheaf(). kmem_cache_refill_sheaf() >> might be especially ineffective when replacing a sheaf with a new one of >> a larger capacity. It is therefore better to size cache's >> sheaf_capacity accordingly to make oversize sheaves exceptional. >> >> CONFIG_SLUB_STATS counters are added for sheaf prefill and return >> operations. A prefill or return is considered _fast when it is able to >> grab or return a percpu spare sheaf (even if the sheaf needs a refill to >> satisfy the request, as those should amortize over time), and _slow >> otherwise (when the barn or even sheaf allocation/freeing has to be >> involved). sheaf_prefill_oversize is provided to determine how many >> prefills were oversize (counter for oversize returns is not necessary as >> all oversize refills result in oversize returns). >> >> When slub_debug is enabled for a cache with sheaves, no percpu sheaves >> exist for it, but the prefill functionality is still provided simply by >> all prefilled sheaves becoming oversize. If percpu sheaves are not >> created for a cache due to not passing the sheaf_capacity argument on >> cache creation, the prefills also work through oversize sheaves, but >> there's a WARN_ON_ONCE() to indicate the omission. >> >> Signed-off-by: Vlastimil Babka >> Reviewed-by: Suren Baghdasaryan >> --- > > Looks good to me, > Reviewed-by: Harry Yoo > > with a nit below. Thanks, incorporated the suggestion!