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 89055EDE9A3 for ; Tue, 10 Sep 2024 16:38:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DE20D8D0097; Tue, 10 Sep 2024 12:38:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D92858D0002; Tue, 10 Sep 2024 12:38:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C59888D0097; Tue, 10 Sep 2024 12:38:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id A8A3B8D0002 for ; Tue, 10 Sep 2024 12:38:56 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 607B8160476 for ; Tue, 10 Sep 2024 16:38:56 +0000 (UTC) X-FDA: 82549387872.29.EA47DFC Received: from mail-ua1-f41.google.com (mail-ua1-f41.google.com [209.85.222.41]) by imf22.hostedemail.com (Postfix) with ESMTP id C0C5FC0011 for ; Tue, 10 Sep 2024 16:38:54 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=KGFEHZQa; spf=pass (imf22.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.222.41 as permitted sender) smtp.mailfrom=andreyknvl@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1725986283; 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: references:dkim-signature; bh=Qc2iqPV1vRnwIRvIBD1uYrgHpwHjN+WZHb7prLzEOTU=; b=O6HIY7aFpeHiBq8w9NiYuvTDVwr5PJ8GQfTfL4ri1XC2KQpN26vMPnlyuZdUphXGpL2EDm lp23sr6nybxZAcKonxZycdzlEcizmZVOA4HRCMiXOhzmPGqDO8fzK25QZ/uR+wg/ZnAwxQ tfsbFj5TkEmtlgVtaNPKiCwfIsRaCPM= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=KGFEHZQa; spf=pass (imf22.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.222.41 as permitted sender) smtp.mailfrom=andreyknvl@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725986283; a=rsa-sha256; cv=none; b=r/YR1B2G1beJosAqWblFDoDNIzGeECfIjK5hXb48DxeHRvjmIjbR5dRaZg2YRtKV1VVEd3 DYd9Gm4KwDppfiyt+iTzQnYmgoa1QGbR1s1upyI02yawcRTyx/rFJ0IsCevczj3Iy92/aN /dbT5+9vbmwcuXB3+ThQLpAVZvrTbvk= Received: by mail-ua1-f41.google.com with SMTP id a1e0cc1a2514c-846d536254fso1708682241.1 for ; Tue, 10 Sep 2024 09:38:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725986334; x=1726591134; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Qc2iqPV1vRnwIRvIBD1uYrgHpwHjN+WZHb7prLzEOTU=; b=KGFEHZQajN55rqNbzmORfOfoX2LdkvVFtttGq3JyQDjlKTK/shNlvgEkxrPQ2M+pY3 khv0VwMZalPEEjIRU9cmae3esDBXymqiN0SAl5SCO6Y24gQXmAj1sPGltli5fdWaznls js1wyj72xyBhvy67NLWss8XAmVeeV09qoAf7NrMEDHgkggcI1kuVuufuWy8MICM0zFjz NFfTchb5HRIVdKp7nL1HeWnyw4qszQZRPxpe9j7L8gtFrpsPC3HxPAWL+1e26pl+elym 7xzTTL3E8AnjiH60e8omKs3t67rsL4w0P4BQ1HZdabJk3VjRHbcjVcrP76jNB+7BVA5J 9ZMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725986334; x=1726591134; h=content-transfer-encoding:cc:to:subject:message-id:date:from :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Qc2iqPV1vRnwIRvIBD1uYrgHpwHjN+WZHb7prLzEOTU=; b=M8quT8F4N2QIdAAp34hh+XHkk1Dj7UKsDZsl3JBzgpEdwmvSVN44zV02hK3Bl3j0DK Sx0Zb8P06mD9kBMtlP4PfM/INJCQbqbU2q/lxf6BNGclWG81PNOUQTX9d8wJMWyjKPFm maSaKWFYvpT+424jJDeNouS/MLap30d97Jvu9Efjfwlr08+3+QEtW1uvNpvx/nj2Z7z5 GMVSONK07+I6JVgH20SCxBPuRHqBuhjidxeUz/O+wk0qNlxlg/xf5V3j9+Osp2ydBTYr GWWrSfRU1vCoUtLqbaqE2y9K2uihbv7CIE3+2MfJnzJNN4RKgKFAwbtm7kr2jCID0trS Nn9Q== X-Gm-Message-State: AOJu0YySM/J1ESfiePMKX7SZYgedc2Kyi2UXirZPSZRYJAlLPN0H/ByG kNzuuLWFuA+c3QpE0osqpe3NWS9grD9pEP4EdXBNwlbm0Y7ZmbHAxrDgGrOOXzKn+BADKFJ9DAT x3kbEFRFM1Xi2Y5U0HX0do5Ta+dSQeELA X-Google-Smtp-Source: AGHT+IHS0P9uQQvz9DK2yT3CoRqXx1KJWW8gCFk0B4Yuakw0MDhmwWcyqiCo+UAXtHDNnj3CM/jgepFikfKaGOOrhnw= X-Received: by 2002:a05:6102:54a5:b0:498:d39b:b0ef with SMTP id ada2fe7eead31-49bde17d7b5mr13556479137.8.1725986333723; Tue, 10 Sep 2024 09:38:53 -0700 (PDT) MIME-Version: 1.0 From: Andrey Konovalov Date: Tue, 10 Sep 2024 18:38:42 +0200 Message-ID: Subject: Question about freeing of empty per-CPU partial slabs in SLUB To: Vlastimil Babka Cc: Linux Memory Management List , LKML Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: C0C5FC0011 X-Stat-Signature: mnqiwbwx5ph4kef399b5xzfj6j1sunbk X-HE-Tag: 1725986334-292168 X-HE-Meta: U2FsdGVkX1/vLzhQ0aH7TQcxlyaqSdapBbSW67tPMOjrC0uxaLsbcLnDgwJnQRvHKKiImX8s3AOQF5yedLmohT5vkPVwpLOvjVB9PjcvWFILBbwwO6/GWgh76P3Dfiy12XicrIFRazPkxlOqWBZY14PT0rraQgjCk4pGy1rq1Tf7zuADtVDO25BnKOy4uxGEt7IWjGLtGxZhfx8vIYUpNgkACYoL3pOb9Hs+E18FUku36QotYsiuOkT7Vc+G/6tzZQhWbX76rgJnEXXInR1KxYJU68la/2T9b0NpY2b68brGgQTQRe1LlAtx1YGjEYrpgHo2N4W1e9wEFaBTfaBrXNvJQwdqRfjLYpmlBh7ATT5POnh3MyoC5m6IFtPpuFBG7sWk4rTS0apY46voLyeO5PWJg76w/MC+eVOfIEVj+MSIRGpq69wn0r4OdNLoPCT/cBv//Jy+h5Z/qkPHNfSjqdFJqNLl7d8KAd+9OgwDHGlq0dWpADckNBk3TVGpyJF5+vR/silELpKwdLPZscGKGySZ0iQQs+0PwNNlKVI1IyPKLwcofYm5t2iC3F0O3jK2w2SocknHwRW3dBipNrEFLJi4NZ5+c2UgZD7WmhhTIZZaX6lF4PYYzQz0NXCW0wzToNhcLZ028aBLvHHiMOttmXGvRTSIEdFAjYKQ4dR4F1aqJ5FT6s9Am5iycBn7sYqNpOSOTChNyNqeULr9vQgik1CAJaQ5DiBQH8pZ90h9bTsBSofnJ9WfCmM7adsKOb+1y8+mdxdXbPDhR+RGKEuV414k7c1Fh0xeFCIrvK74LRKVwTyLh5tnj32tFbp81MnawqQzY+ZWckX2MdKhWKXhTFB6OIlCjyOO8SZLyxNg668jC+7liUHgd5MVgvzyh/hgHYM404egCeEishjLLc/BQ8TTIpybBY11g8OCoDZA5iZihQA5vEW1p/C6zL5PB4Zuczhi8E6TpVKD+PFy1MM W0B0JoOi vKt7qq45IVbgedr08HdMt8JTOsfNvWDBJwA197rWx5WjtfhzwtIv2lI+LGMWxPjA69mudGtmQ5jjKMRKTpSznyIBS/fdE5cVCZSf9d880SmBLkNyg5P5M0DWfd6ru40YKk/6monrFQ5q2D7zzVGKXbjefGFdSKUrZ/VtqLbiX8Qwuw4XWgahwlLYaWHCnIzSruWBqcIPwIZysu6pA6D2L2/LIlGnL3MsYONbBjB5Lo7jBg/q9yxQGE85JNnzon7/I3RVFXP9fbVLcW1C1EgonzrdQTveha3BmDYvocg7SjaHRdI2nZtVXteXH6LZrLD5upxiUX5Wf1R5+CN//zwRJHkTgxKsbHzQNKmaGLrCTpwYoBVlL8VgXbvrAIg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.001800, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Hi Vlastimil (and other SLUB maintainers), 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: "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=E2=80= =99s 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 >=3D slab cache=E2=80=99s min partial) then the newly available empty slab is freed a= nd 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)? 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. I hope you could clarify this. Thank you! [1] https://blogs.oracle.com/linux/post/linux-slub-allocator-internals-and-= debugging-1