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 53845FA3754 for ; Fri, 13 Sep 2024 13:27:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9A4036B008A; Fri, 13 Sep 2024 09:27:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 953296B00CB; Fri, 13 Sep 2024 09:27:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7F4DD6B00CC; Fri, 13 Sep 2024 09:27:17 -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 6208A6B008A for ; Fri, 13 Sep 2024 09:27:17 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id CEDB9A1FA5 for ; Fri, 13 Sep 2024 13:27:16 +0000 (UTC) X-FDA: 82559791272.08.451711C Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.44]) by imf17.hostedemail.com (Postfix) with ESMTP id 0D41A40009 for ; Fri, 13 Sep 2024 13:27:14 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=i0ivD9GT; spf=pass (imf17.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.128.44 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=1726233894; 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=/dWHW16qX2DkRGWXpD+15atzONRgFU19ebFt8gO5Rx8=; b=VU6dLq3aV2xQNvMhREPdPbjPJb/76vf8GeQbaAJPK5nY6uyauwfjUtEs6MCsn1e0r71P5K ANZ88ig5moyKyIdPDhZxl6nmWlGNI/91sJfLFaWY0VMDQEO39xGHXEApMHhrI+xpnrOsqy AmBVPOieQcGk28q2p7MiOgGjp9eWTZs= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=i0ivD9GT; spf=pass (imf17.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.128.44 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=1726233894; a=rsa-sha256; cv=none; b=jg7HgH/kNVF1FUktr7iSsgyGDe0ALUpVRdXVzUjSK1nkOntWT/XqWHoTVfqMXdkCRSTDa8 0wr4pUYv+h6ectrSLSnsHlzSE87BlAQq4CmMJoPxf4/dzje/aJYCvVsA7rsnNGEkttLQ8k wzGkYhuxWT7gSIJWXyeu70QusX0TEKU= Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-42cbe624c59so8203935e9.3 for ; Fri, 13 Sep 2024 06:27:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726234034; x=1726838834; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=/dWHW16qX2DkRGWXpD+15atzONRgFU19ebFt8gO5Rx8=; b=i0ivD9GT7hA7Px/6GZrxJtEiaT8X/BdbYopcLNrKcZYuBdI9c0kMZT+tTO0673GrGv okCUslQt8bGPs8ulcZZ3o3B4Htpv7Pl/Ghlov9OUal23948w3V+4TFfYWRClTtAsdPQL mbIejmlRXawtFjRfXk4Aq0a9buT4Ob7x80tQyPlD9DUZetFYQh8LkgwFHGVnnHyrgDPB JELel83ztFSLMll2oKi400NFSZc37eFXi6/QDYQQrNPjqQLySOEc9w9R0BqYoDklA5aB E1VhjGbDZb2LQNx3hFl/NI5jG5rNknkxBkeMwy7feyOYuy0ELFr8wToAZ+RaIwrpbZ+k 9Mhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726234034; x=1726838834; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=/dWHW16qX2DkRGWXpD+15atzONRgFU19ebFt8gO5Rx8=; b=ahQQxpLA5XaIDxcaMakAWmjtxwCOYkb0CdEK6DtnmQpsj6LMtI2HyNGqdpckQbJMWY JYa4u+tv21rWXIoqXt+LY/d1WC0pP1YTwB1dsCvrNKKkUKNsxidEXnK1dsZWTKBKw546 r/hna0aCR7v8LvPYT7OQgdF2a+IXhxhV27NaTMT0FaI3ZqajeaTjEou/aCFikQdiTcsU h1/Q8Z/mkozsVi9rjnmV0fOdGxRbXH6sYRbC727GPlWBTz0L3hEJXX3l0+b9QCLPAeTv ogzPZvZCDgtNBd+NRUAEt32W9c7buP6Xb4lCn5gTNq8CYB6JqkVtad5vEq2MzDRYGymK ZZ1g== X-Gm-Message-State: AOJu0Yx+JQhaFKdmrkbLbFP21LSLzVkzt8TAON70epFgFwkLHdfK5G7+ lumEfgQKHsy1MU/dYXMTBW/aETtRFwGAprRDxUJ0t13ZPfdTtN2LO38fOaLRmx861Z5QwL+K6pu ou1XLvEeeXU19WQeWqpVOXXtK+Fg= X-Google-Smtp-Source: AGHT+IECze5FuOLdpZqptn6lvbr71iYBCuyk7Xo54O53SFoEfeNUpJXM1nvOPEYA89clAzHMc9s2ERGAopoHd0CbbNw= X-Received: by 2002:a05:600c:1d05:b0:42c:c08e:c315 with SMTP id 5b1f17b1804b1-42d90827159mr26429435e9.16.1726234032925; Fri, 13 Sep 2024 06:27:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Andrey Konovalov Date: Fri, 13 Sep 2024 15:27:01 +0200 Message-ID: Subject: Re: Question about freeing of empty per-CPU partial slabs in SLUB To: Vlastimil Babka Cc: Linux Memory Management List , LKML , David Rientjes , Christoph Lameter , Hyeonggon Yoo <42.hyeyoo@gmail.com>, Imran Khan Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 0D41A40009 X-Stat-Signature: wp54176oe67hbutsgtyrwupee8gzndrn X-Rspam-User: X-HE-Tag: 1726234034-238717 X-HE-Meta: U2FsdGVkX1+51OeZpJyeIL2A2sE0BmbQhrwalutQHZrSvGNajjykGKE7Fm+10EBNC/5cOzqznYoF1SWqrvH11UwNxyOMd/uMmgtUPT2n4pMuJWEenSVRRgGgptJZUv5jyRDWOhH6I96WgmoGq8dJ1HCxV8TzOTVyEGMt8kIxtwdYvzyiHXemyBydKsl9XVrsiQl0ABU8hXGa9TtkLujFDnOloj71vbLnLuotgJdbPSJR6eNT0mP9kgsBzISaVZf9CEq52+hoj2PHH/1Zy381p/c3xn3fGLFyDYc11d+ylUNO/+Mxdb8FZicbQ1k3VEel2AuZqjX7no5SxL3IW3D2mKiTlmB/izcYsUbIRdjOarIDRjhSr5m5OGsDF9TCGqxAmSpuTDTKrwwjOazMX3262ybEPh+DZr01BXRh/JJWMn8SFTAwUKMZeZdiBtXYwMOUFFQkZFzr5v0yLYpA/W6TR5oCYBFbnIoOVz0m7gNg608pNTYE+Xh6Fqarbfspo6j3lm2QtHuRgSLxVTNn5NsHEVtnoWWGmPTNj/vKHwVAydPeSbI7PM/0E7ESyO3CylPr+dXVH7M+owxqNrh+V6/Vu6rHxlGhes9SsOsyG9KFq4XRrQkX5hg9gMYmJjeZ9SVonoMtFP91nNz5ND+AnyPQFg1XptOUMjocBGDVzQ6m2CxHY6tzRsAib4wosWB1rEll7MMq/hu2qIdROxqxwlVJCVztsEljnBzLwVTI+aQOmQf4wAajl13yh0cpF7zX17mCEbwoQcXpXxPKcuxmt0SPPH17MKn8InkUR6BJl4ngR5hj7nscUab1ToDYGYnBvpnKv88Zp1cL5knilLGTrJLRddgbB7oLRcI77dKKJRbPxlnE8emTiyRUgdDTiL+6icMAixhvFIRRddpm4gtx1IDYYWfG/9en41tL0Pktppr7XgCqOjySO1BPSSWFxjeXBH9MXHOkdSlAm4V/l0tAEFg 3hFDIrZV VJFLgNtM2/CKjhA/4IaZeq5tAlSjt0Yhbs6SfuBg1UDLBPlkqiL6jAHT/wZx6RqnYKBPTd8MkJlSxbXciGmj0aMXPmtoYr00ylvMZJ0qtxqqbwzqfjfkRCASp6+/zfiOLviRqcp3OtP7k/fbJuL1sCOebKeY1e/1Y2netzPDAz7BZ52h3/9U1JoMSHSa4wFeCF2xrNk6jNk0aiyFRsjOz2xriraXUmQnacnurE5H3fxhgZ5YCxViV/7KhnlaiZAT4S3yeKa3W1FrrM9nxvW+SelvhVoXAqmG81vCkSTJn0xtNpPOO7ysPln6xioRrlY6UCtp594wOAWl6IsryeoZUdA3e6JJI/SE5+X10Kd1eNqHRjdit/gC4UQ4xnZty+9nsacSS8zvdeEcyldI= 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 Thu, Sep 12, 2024 at 10:34=E2=80=AFAM Vlastimil Babka w= rote: > > > "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 fre= ed 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 pa= rt > of the preceding one: "However while putting this partial slab on a per-c= pu > 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 unfro= zen > i.e they are moved to a per-node partial slab list and this new partial s= lab > 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 t= hem > 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 appli= es > to both..." part is correct, although as you say it cannot immediately > affect a slab on partial list we are freeing to. Ack, thank you for the response!