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 A470FEEB565 for ; Thu, 12 Sep 2024 08:34:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CCDBC6B007B; Thu, 12 Sep 2024 04:34:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C7BB26B0082; Thu, 12 Sep 2024 04:34:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AF5AE6B0083; Thu, 12 Sep 2024 04:34:38 -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 8F86A6B007B for ; Thu, 12 Sep 2024 04:34:38 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id DD568C1DFD for ; Thu, 12 Sep 2024 08:34:37 +0000 (UTC) X-FDA: 82555424994.08.F50D108 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by imf28.hostedemail.com (Postfix) with ESMTP id 78306C000C for ; Thu, 12 Sep 2024 08:34:35 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=ieZZFiIM; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=enyGsZuL; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=ieZZFiIM; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=enyGsZuL; spf=pass (imf28.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.131 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1726130022; a=rsa-sha256; cv=none; b=hq4EiC5tZte4CMpflCIk15xghRrHiixPJucTYOW3i7sBfPI2TOmdsLBcXJVGkcl3r49Zkj 09IgyZueLbm4T3HIXLtmz29G7gmuNYgyjPQY+XWf4PMjS5NaN/0FT4vJti8MdFGxidBSdV v6s2nQ8hAzfYpLevxfGbGAjDlZNjuQs= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=ieZZFiIM; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=enyGsZuL; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=ieZZFiIM; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=enyGsZuL; spf=pass (imf28.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.131 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=1726130022; 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=vSlW2mj6hD4LR8e4gZcftplwnj3Y6rJwu2Q/qh132ws=; b=i4tYH8H/2Ubp1KXQhuYH3ZenibcW2ykAjtivpdH8BXe1irSwtpp/xFxw/BvhGWV24Gm/oE qpioNtZM7n9t3aJu7N9ea3WZ4B62sXqstARYrzdtibXDRwWjDDqOuKhfL4GyuFyqspFNlL 3sJWy8tutg4JngH6mC2tUXCsl+VGcuM= 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-out2.suse.de (Postfix) with ESMTPS id 6797F1F749; Thu, 12 Sep 2024 08:34:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1726130073; 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:autocrypt:autocrypt; bh=vSlW2mj6hD4LR8e4gZcftplwnj3Y6rJwu2Q/qh132ws=; b=ieZZFiIMP5aHssROuIp4Jhg4OSalKWvMbOdsunRFbXSgcza58pcLTC/DTQYoeBFAViWin+ DHfUbQAloMkokau70DbacxBtjLb5CObAqHH7vvJcTzwoy/vszq7erLNOkoClUKyKHVBlkV eTk4AtsoaV6VyD4iYW814wX2fT31lFI= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1726130073; 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:autocrypt:autocrypt; bh=vSlW2mj6hD4LR8e4gZcftplwnj3Y6rJwu2Q/qh132ws=; b=enyGsZuLGxxaBGRlOQkwdTC0dbHpXmAObY7F2CKboLiYoFy2qWfVnDwFN0K+qSV21NvXNW vHnOj9NcWdK2qHDA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1726130073; 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:autocrypt:autocrypt; bh=vSlW2mj6hD4LR8e4gZcftplwnj3Y6rJwu2Q/qh132ws=; b=ieZZFiIMP5aHssROuIp4Jhg4OSalKWvMbOdsunRFbXSgcza58pcLTC/DTQYoeBFAViWin+ DHfUbQAloMkokau70DbacxBtjLb5CObAqHH7vvJcTzwoy/vszq7erLNOkoClUKyKHVBlkV eTk4AtsoaV6VyD4iYW814wX2fT31lFI= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1726130073; 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:autocrypt:autocrypt; bh=vSlW2mj6hD4LR8e4gZcftplwnj3Y6rJwu2Q/qh132ws=; b=enyGsZuLGxxaBGRlOQkwdTC0dbHpXmAObY7F2CKboLiYoFy2qWfVnDwFN0K+qSV21NvXNW vHnOj9NcWdK2qHDA== 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 54C2B13AD8; Thu, 12 Sep 2024 08:34:33 +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 f59WFJmn4mb+DwAAD6G6ig (envelope-from ); Thu, 12 Sep 2024 08:34:33 +0000 Message-ID: Date: Thu, 12 Sep 2024 10:34:33 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Question about freeing of empty per-CPU partial slabs in SLUB Content-Language: en-US To: Andrey Konovalov Cc: Linux Memory Management List , LKML , David Rientjes , Christoph Lameter , Hyeonggon Yoo <42.hyeyoo@gmail.com>, Imran Khan References: From: Vlastimil Babka Autocrypt: addr=vbabka@suse.cz; keydata= xsFNBFZdmxYBEADsw/SiUSjB0dM+vSh95UkgcHjzEVBlby/Fg+g42O7LAEkCYXi/vvq31JTB KxRWDHX0R2tgpFDXHnzZcQywawu8eSq0LxzxFNYMvtB7sV1pxYwej2qx9B75qW2plBs+7+YB 87tMFA+u+L4Z5xAzIimfLD5EKC56kJ1CsXlM8S/LHcmdD9Ctkn3trYDNnat0eoAcfPIP2OZ+ 9oe9IF/R28zmh0ifLXyJQQz5ofdj4bPf8ecEW0rhcqHfTD8k4yK0xxt3xW+6Exqp9n9bydiy tcSAw/TahjW6yrA+6JhSBv1v2tIm+itQc073zjSX8OFL51qQVzRFr7H2UQG33lw2QrvHRXqD Ot7ViKam7v0Ho9wEWiQOOZlHItOOXFphWb2yq3nzrKe45oWoSgkxKb97MVsQ+q2SYjJRBBH4 8qKhphADYxkIP6yut/eaj9ImvRUZZRi0DTc8xfnvHGTjKbJzC2xpFcY0DQbZzuwsIZ8OPJCc LM4S7mT25NE5kUTG/TKQCk922vRdGVMoLA7dIQrgXnRXtyT61sg8PG4wcfOnuWf8577aXP1x 6mzw3/jh3F+oSBHb/GcLC7mvWreJifUL2gEdssGfXhGWBo6zLS3qhgtwjay0Jl+kza1lo+Cv BB2T79D4WGdDuVa4eOrQ02TxqGN7G0Biz5ZLRSFzQSQwLn8fbwARAQABzSBWbGFzdGltaWwg QmFia2EgPHZiYWJrYUBzdXNlLmN6PsLBlAQTAQoAPgIbAwULCQgHAwUVCgkICwUWAgMBAAIe AQIXgBYhBKlA1DSZLC6OmRA9UCJPp+fMgqZkBQJkBREIBQkRadznAAoJECJPp+fMgqZkNxIQ ALZRqwdUGzqL2aeSavbum/VF/+td+nZfuH0xeWiO2w8mG0+nPd5j9ujYeHcUP1edE7uQrjOC Gs9sm8+W1xYnbClMJTsXiAV88D2btFUdU1mCXURAL9wWZ8Jsmz5ZH2V6AUszvNezsS/VIT87 AmTtj31TLDGwdxaZTSYLwAOOOtyqafOEq+gJB30RxTRE3h3G1zpO7OM9K6ysLdAlwAGYWgJJ V4JqGsQ/lyEtxxFpUCjb5Pztp7cQxhlkil0oBYHkudiG8j1U3DG8iC6rnB4yJaLphKx57NuQ PIY0Bccg+r9gIQ4XeSK2PQhdXdy3UWBr913ZQ9AI2usid3s5vabo4iBvpJNFLgUmxFnr73SJ KsRh/2OBsg1XXF/wRQGBO9vRuJUAbnaIVcmGOUogdBVS9Sun/Sy4GNA++KtFZK95U7J417/J Hub2xV6Ehc7UGW6fIvIQmzJ3zaTEfuriU1P8ayfddrAgZb25JnOW7L1zdYL8rXiezOyYZ8Fm ZyXjzWdO0RpxcUEp6GsJr11Bc4F3aae9OZtwtLL/jxc7y6pUugB00PodgnQ6CMcfR/HjXlae h2VS3zl9+tQWHu6s1R58t5BuMS2FNA58wU/IazImc/ZQA+slDBfhRDGYlExjg19UXWe/gMcl De3P1kxYPgZdGE2eZpRLIbt+rYnqQKy8UxlszsBNBFsZNTUBCACfQfpSsWJZyi+SHoRdVyX5 J6rI7okc4+b571a7RXD5UhS9dlVRVVAtrU9ANSLqPTQKGVxHrqD39XSw8hxK61pw8p90pg4G /N3iuWEvyt+t0SxDDkClnGsDyRhlUyEWYFEoBrrCizbmahOUwqkJbNMfzj5Y7n7OIJOxNRkB IBOjPdF26dMP69BwePQao1M8Acrrex9sAHYjQGyVmReRjVEtv9iG4DoTsnIR3amKVk6si4Ea X/mrapJqSCcBUVYUFH8M7bsm4CSxier5ofy8jTEa/CfvkqpKThTMCQPNZKY7hke5qEq1CBk2 wxhX48ZrJEFf1v3NuV3OimgsF2odzieNABEBAAHCwXwEGAEKACYCGwwWIQSpQNQ0mSwujpkQ PVAiT6fnzIKmZAUCZAUSmwUJDK5EZgAKCRAiT6fnzIKmZOJGEACOKABgo9wJXsbWhGWYO7mD 8R8mUyJHqbvaz+yTLnvRwfe/VwafFfDMx5GYVYzMY9TWpA8psFTKTUIIQmx2scYsRBUwm5VI EurRWKqENcDRjyo+ol59j0FViYysjQQeobXBDDE31t5SBg++veI6tXfpco/UiKEsDswL1WAr tEAZaruo7254TyH+gydURl2wJuzo/aZ7Y7PpqaODbYv727Dvm5eX64HCyyAH0s6sOCyGF5/p eIhrOn24oBf67KtdAN3H9JoFNUVTYJc1VJU3R1JtVdgwEdr+NEciEfYl0O19VpLE/PZxP4wX PWnhf5WjdoNI1Xec+RcJ5p/pSel0jnvBX8L2cmniYnmI883NhtGZsEWj++wyKiS4NranDFlA HdDM3b4lUth1pTtABKQ1YuTvehj7EfoWD3bv9kuGZGPrAeFNiHPdOT7DaXKeHpW9homgtBxj 8aX/UkSvEGJKUEbFL9cVa5tzyialGkSiZJNkWgeHe+jEcfRT6pJZOJidSCdzvJpbdJmm+eED w9XOLH1IIWh7RURU7G1iOfEfmImFeC3cbbS73LQEFGe1urxvIH5K/7vX+FkNcr9ujwWuPE9b 1C2o4i/yZPLXIVy387EjA6GZMqvQUFuSTs/GeBcv0NjIQi8867H3uLjz+mQy63fAitsDwLmR EP+ylKVEKb0Q2A== In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Action: no action X-Stat-Signature: w384ex44b1e8pzpxc3dxnbctptg3rraa X-Rspamd-Queue-Id: 78306C000C X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1726130075-20369 X-HE-Meta: U2FsdGVkX1/LrjUnPv7wLKviLURw4cFbxFRHqAUsgN1MdbrVoY6bTy5vHuJivVHAVBnwo6WWQSPFWEaeQfC7k0GGsg7retmhQsw0jBcn0zo3NJmWp+uvIemSc8pEpi/pwk5f54UuYxbpAOqGNidjAx+PiFD6SA9fXXGTV61d0dEZx1CvJBd95+3V5P7cpRpE5ZHTvBGcqPqNMHEMjGKsobC6SFevW1DaizOA69/0JMWavPEt0+K9StEKWIiHiOP+gq1/cY5BJIL9OO9WFnzj3BshmfYsh5KbfktT/38RPzx1MVhH10YsVoU3+zuqMzHap7Lcdh/FHe9wQtjuzkX1bswPfR6gzKA3R7Jdkfn5dJ1ttyME8lmYtf80eM7To+AfoX0Va0xBTjYycpKze4al7GvpZ1cvS4a6pl5uHu2wS60KNl2BanzJfpv520f80yuyKnn4addAJiWzqHK/5RFRLzD/Jaqr1ipkLZUG66xqAc8GP5t5pDXcPHA+j3J+dWZEOzhQ8rCUCYnZdVQeCSd/epTRSAvH1QY98KlS96sR0KMchKIIeCJd8foJv2xOvL28QxZGUHX5goTwdqnGgJZX8euq07WBDV1FOH6d5HX6vL+1ie71zmgZLzuQ5OeoSeVkEueIJYGgWThjvHq/yyqUTLRNHFR9MauI2kg6R9JaZMKpMdZQcW2om6s8b0+jH4xF/W725xL2fI886sd4CPVMhby3ug684kH32eP4N61tOnVIJiwoPix9JjzR6cir+BtFjNRU7CcApj78v2Rn+l2XpZsrSZXqVSHG+ileLsxWsnWi4PI9xWLVlt7ZdcspX0YjZBzqMAVVmZBqqRUhBqKwwE7396vXSFg94hsc0yMHvDx8OtA+gw5fifPKPEpW7ZHJC2lCE/sz8aFSdRFM0MxwCahUeIkCpJ4GDYOboVmXq2Ju6OftwjSUr6VbT+FOts8tSS0+STTmldbil11W54e p80LDi7W aIJv1xpnS8sIpVKgornzSLn3jl8q7RwZgrYNYnFbEUsQLaYhTBuAA9AKTpOs1lIh8k+ftC/t5vfqgb8EQyrmLDFjKPuP91Hxoh38XMhwTACRMQE9xLzVGY5pGWc8r47lppbZslRKwegFefe7YhgCHO0SudT+hiUfsjWi1++S1bgtb85DQADcBdb46ydl9zXuC+7UytnHYpAVgFrxNuN+gT1JR5Z+fDX4hkzh6o880JnGaXVFJR6CKQPQ8aDpqVPX2/1DyPKsOHjnq1Wms6MB+rcLQjQ16O8isth4OPeVH/Yf0AF76fFt3GFrdIQg8zeEa1zhRb58zW1SOeIaISVfxCaGlYrdM0QULyv/y9X8AW0+v0UZ73uMCVqO382xzSvj8RsGaLXXT+ExIpHZtOsaJQ5BGlg== 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 9/10/24 18:38, Andrey Konovalov wrote: > Hi Vlastimil Hi! > (and other SLUB maintainers), you didn't CC them, so doing it at least for the active ones... > I have a question about freeing of empty per-CPU partial slabs in the > SLUB allocator. > > The "Linux SLUB Allocator Internals and Debugging" article [1] states: And we can Cc Imran too :) > "If the partial slab becomes an empty slab after freeing up the > object, it will be left in its current list if the number of partial > slabs for the concerned node is within the limits (i.e < slab cache’s > min_partial). This applies to both slabs belonging to a per-cpu > partial slab list and slabs belonging to a per-node partial slab list. > If the number of partial slabs are outside the limit (i.e >= slab > cache’s min partial) then the newly available empty slab is freed and > is removed from the corresponding partial slab list." > > The part that seems wrong to me here is the statement that this > applies to the per-CPU partial list. Based on the code in __slab_free, > it looks like it cannot reach the slab_empty label for a slab that is > on the per-CPU partial list. > > (I know that an empty per-CPU partial slab can be freed when the list > overflows or via shrinking, the question is about the slab being freed > directly by __slab_free.) > > Is the article wrong with regards to this case? Or did this behavior > change recently (I failed found any traces of this)? I don't think the behavior changed recently in this aspect, only in some other details like tracking on_node_partial with a page flag for better performance, and slabs on per-cpu partial list are no longer frozen. I think the paragraph you quoted can be interpreted together with this part of the preceding one: "However while putting this partial slab on a per-cpu partial slab list if it is found that the per-cpu partial slab list is already full, then all slabs from the per-cpu partial slab list are unfrozen i.e they are moved to a per-node partial slab list and this new partial slab is put on the per-cpu partial slab list." So while flushing the per-cpu partial list, the per-cpu partial slabs are moved to per-node partial list, and when __put_partials() finds some of them are empty, it applies the same s->min_partial threshold to decide whether to keep them in node partial list or free them. So in that sense "This applies to both..." part is correct, although as you say it cannot immediately affect a slab on partial list we are freeing to. > Other than this statement, the article seems to be correct about all > other small details that I looked into, so I'm not sure whether my > understanding of the code is wrong of the article is. Yeah I like the articles too. Checking the code as well is a good strategy as it may always evolve further since publishing :) > I hope you could clarify this. Hope that helps! Vlastimil > Thank you! > > [1] https://blogs.oracle.com/linux/post/linux-slub-allocator-internals-and-debugging-1