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 608F8C282DE for ; Thu, 13 Mar 2025 11:24:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8A59E280002; Thu, 13 Mar 2025 07:24:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 85645280001; Thu, 13 Mar 2025 07:24:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7200D280002; Thu, 13 Mar 2025 07:24:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 550A4280001 for ; Thu, 13 Mar 2025 07:24:11 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 0F61EC1FBF for ; Thu, 13 Mar 2025 11:24:13 +0000 (UTC) X-FDA: 83216293986.21.BD1064A Received: from mail-ed1-f43.google.com (mail-ed1-f43.google.com [209.85.208.43]) by imf25.hostedemail.com (Postfix) with ESMTP id 1BF1DA0005 for ; Thu, 13 Mar 2025 11:24:10 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=QOfhZHjH; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf25.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.208.43 as permitted sender) smtp.mailfrom=mjguzik@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741865051; a=rsa-sha256; cv=none; b=JW/97k6sQP6jO0HDyUe3F6h0KBtBLo5tc1th1X4ubVQcpnP0Ipt7r9nVZOz+L0TIkHOeaT XcP45K663SpAC0fpBBL2K1KFBYHVMscMNT7rS5mp3UXr2hryhx2ECM4GN2Y4n8H6t03/zy VwmDhNvwhHLH6YOWLk5XRLODdoDuwEM= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=QOfhZHjH; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf25.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.208.43 as permitted sender) smtp.mailfrom=mjguzik@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741865051; 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=7SOZiFuvkuodg/BhEEgT27LeEuerVoiY44tMvLbJBVw=; b=jMiWOUlwjnFinNZJ2RgWFijZMv3Wab5ilNSqmGyVd2RDs1ebxB3r0lWiOg+pWBPG3ksJrP c0ClW+Q0fEnqw8uzWAqwpu/CEv+cLyTHBrvoWA0YlAssWwz0kqp/ihnfIcJxtJLO9D33we gDqzrxsNsuLHV8ENuOt/Y4B50fl5y4M= Received: by mail-ed1-f43.google.com with SMTP id 4fb4d7f45d1cf-5e5deb6482cso3494814a12.1 for ; Thu, 13 Mar 2025 04:24:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741865049; x=1742469849; 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=7SOZiFuvkuodg/BhEEgT27LeEuerVoiY44tMvLbJBVw=; b=QOfhZHjHhYPKhS7qnWD1fx4mKyUgtEWR0lOBt6Oz1IiX4ZrwMXWzVNMKzbkPLcF5Mn NO+kPoRNnSqMxU/eKm5rVg+HwYjKCjg9nxbjVK9c6Uw/jzHiK1Tj9AO1e8R6KEqg3DHe 6Jo/dwAlrGLF4rS9wYxp18/uqne1mFDqBkcvgQ05D9lxpDFRLKN9kFXXzvHyaKUXwC1S kxz8tM56YVFARpU0TZcWh4Z5ig1BVLRUjW0rBaMbzTOlBoS+9e7MK/ss+vergTqxblHq sL/jQq2pNLw2QtXdfXXRT/QYWQnbV+/s4Img0gSDYSYIXSTqPDvqnizVSKSlceN+2y+X 4ZgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741865049; x=1742469849; 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=7SOZiFuvkuodg/BhEEgT27LeEuerVoiY44tMvLbJBVw=; b=Uxi0UYILP7QnI7lftrqwyOwEIqoQwpbCsdsweb16fWI31dQlOI49JwLc2dJaDksLCJ hvxmEHqGa8xoPDBq0RRdoK4OQ4cfDcysZ6V6YNn36VlZkLwRV4lI4JQnYVGvSg4wLcNw GqieJpGWNN7xHJnSv+qLGBQFxE5x78ua/UTfdbEgP/PE2ASORoVDYCNDnKJJxIhx989j 2zn2JpegKFgwDuNsd7K7vJ7HBwOZUZO1gB8k3xDW1l2iQNWVDCEB4xrI/ZuzkfVOV0K5 HrxikLXS3cI5ab5kGz4WuyyDZ21lH+wsbpO6orxkBQNpdfqw0eTANenP3syv5/CesZLf PpCA== X-Forwarded-Encrypted: i=1; AJvYcCU3Ak2oE/j62f+EvU4PhLlsvPe8tdmjYlHLU8N48DMMJSRAg/8czBPzCoZ19Q71Bh19zmfwIOP5aQ==@kvack.org X-Gm-Message-State: AOJu0Yxz4m3CNTtj50LvfhVA3YamAq7thJ+0gDaQH51hum554SZ5hKju FIEfvRc/Vc8DijJwFZ+CDlLKOTe4lJtFIrxvXqYx1QIoQk+7+ngBEdRXx5BgoYV5eDzIga+NJI2 SfU1fnTiOTn21PPBeIoe7iNYxeJ4= X-Gm-Gg: ASbGncvVsXORcrcaX5gzkFQ34KDAqUpjx8WJvOBZ4RpQz0OxQlVKxWCTpMbCciogsGz 3gi7ce9xXcK9344GRu3OpuHIzZrP8TfeaLEi0QLAYFiN3PNeHLRDjen7EkAfgEazix3pxrHfy8O SKNhKTUV3+nNMidCwBZR8fAW2KUr87uD9KUS6L X-Google-Smtp-Source: AGHT+IFQecvBgxuBT+Nd+XPCjUN22al+XRhm6XIpUsrki0pfNdGwNuXUecQTrvkT4n1ZsQc8eFdS1Q33dCOkOTEGw+E= X-Received: by 2002:a05:6402:5252:b0:5e5:4807:545f with SMTP id 4fb4d7f45d1cf-5e814eb3bfbmr2216157a12.12.1741865049161; Thu, 13 Mar 2025 04:24:09 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Mateusz Guzik Date: Thu, 13 Mar 2025 12:23:55 +0100 X-Gm-Features: AQ5f1Jpu3nPfhYNrrCQmNRld8AEiQGX7QnltoA8_wK97p4gAF3rm5uINtlXKizo Message-ID: Subject: Re: a case for a destructor for slub: mm_struct To: Harry Yoo Cc: Vlastimil Babka , Hyeonggon Yoo <42.hyeyoo@gmail.com>, linux-mm , Dennis Zhou Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam07 X-Rspam-User: X-Stat-Signature: jrn36hbje54p18egxrp38b98euotbhaq X-Rspamd-Queue-Id: 1BF1DA0005 X-HE-Tag: 1741865050-275250 X-HE-Meta: U2FsdGVkX19AI1Mu2fT9bVD3YUgAMh8rX/gYGseDp5LGSoiIVKaj/2hgxzwaseimV4ilZYHDhuANfGEifEmi6zW1oQLCG8MJ810D5PowMdXntreOedAmx92P5p1Q/Ir5WRh1kC5G3etwoR4XK5Doxi54malPhY4zQc7s1VWUEl3xtIGB4jEuCRk5/muC0ryo8T256tQTDgqVSkIZqRx5f+oQAkWsK7y3vHedoV+vjCWf2/meRGZ3MF52Gj0Pi6ubgq4lY1ggdxoXJieeE2ec4KnJ87v2z1D2hQSZfYfhzxE+C5P61RWLly38KZeCF66YRzbxoNeXk3RCJ8Nd5mVbXWejstoIXa37nSrXb6ShatA6Was+ujXl359NAXy45PEbriXfioPk/HtuhM/Zm8gfMv4tbL5YGmEAoiWB1NIk6rO4VKaQp52pJpJdBzB9KTQsgSTvEH/v4dkjEc2GBbS4PdczrbLg6Z95DTmQ8BwU3b+bDkkWnqDjFc9eWzQjB804hOZvI664Z6zJMm0ECdna958wVcdNbttT6k7OAt41UoK4YPATQgIuaC8EtQ6dN81eWGm5TYnJ1A/NXbF2sOx95LjUaJmkRmpR/H5e4gOC7SwcgRjbvsK3uNGZAGdJy4dmpigJTP12GNBWiRFJXE7uk8O1WlwOxH+vg0PLJjuojUqVQH0/+8MUtrG+bC11AGzFszW/ySG5ywH9ze+lZr7Q/xcGXS7HSMaKN/q0CPWIjOdiv2xzQoJXLQyJ0RxCx3Y51BgGEQmRtjgmuv79IfsDCYmNAB0sU5gDrIMX/AUH+X3rM+FIPiZegpbkOY1gcLvXl/DnatL0wsTq/pcCm54F0pi3tzxpBVO9+F6KjpuSBTMrUsVmRlMohSi5CBGV1lMsn90IkmBn7emqaghapyG5hGN/a/doykQwvqyU7lb39h0uY2Jn17e0uYTaXa2FQt/sgKaRAPo56+06+Q/ir/o jZW8eFnb roZ9AwsL45DVwnMz7UUjkyh+tfD0MZXIE3xo7c3umGZARplzfbI6I0W73Pgj57JIRwk7XFSsfhoWYPbOWRzgteU1JUnHvXsqL/uLXVULHXcU+NtVlvymrepvVfQJuySgi1XDo5CEeDBhoaLT0M+bIZnm7sAv2qcr9P3p3oKcGcq735rul/JFHNYbe5LUZFauoWoKD5JrNuZx0HcMG1JZtrQe13ty7EXUdZ8o79pxzGllKjSap9J5aW8MRiT9RoXIEX6FpLg3s4k8zJ0ZFh6oXh4UzqGTHAd/k9e8xbrjKsHBzfuStleri52aXl3bEdBV+OjknUQHLDblXkMvViiEoq1KBtwjr5ckQLIeJvFGzaktJVeJnLVdUK3Hr2fyQyyxRixATw3lXM/1woQzYn3dt7VkSD9CsGLEw4RRjhjlZBQhLPScrDJdnxU1W+IpRZXsVpq8QauMLmZGTjuw+OAbLtP9BaInXhORVX+vH 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, Mar 13, 2025 at 9:59=E2=80=AFAM Harry Yoo wr= ote: > > There is other expensive work which can also be modified this way. > > Not sure what you're referring to? > There is pgd_alloc/free calls which end up taking the global pgd_list lock. Instead, this could be patched to let mm hang out on the get skipped by the pgd list iterating machinery as needed. > > there may be spurious mm_struct's hanging out and eating pcpu resources= . > > Something can be added to reclaim those by the pcpu allocator. > > Not sure if I follow. What do you mean by spurious mm_struct, and how > does the pcpu allocator reclaim that? > Suppose a workload was ran which created tons of mm_struct. The workload is done and they can be reclaimed, but hang out just in case. Another workload showed up, but one which wants to do many percpu allocs and is not mm_struct-heavy. In case of resource shortage it would be good if the percpu allocator knew how to reclaim the known cached-but-not-used memory instead of grabbing new patches. As for how to get there, so happens the primary consumer (percpu counters) already has a global list of all allocated objects. The allocator could walk it and reclaim as needed. > > So that's it for making the case, as for the APIs, I think it would be > > best if both dtor and ctor accepted a batch of objects to operate on, > > but that's a lot of extra churn due to pre-existing ctor users. > > Why do you want to pass batch of objects, instead of calling one by one > for each object when a slab folio is allocated/freed? > > Is it solely to reduce the overhead of extra function calls when > allocating or freeing a slab folio? > The single-threaded overhead is one thing, some contention is another. back-to-back acquires are a degenerate case from scalability standpoint. While these codepaths should be executing rarely, there is still no need to get spikes when they do. Even so, that's a minor thing which can be patched up later -- even a ctor/dtor pair which operates one obj at a time is almost entirety of the improvement. > > ACHTUNG: I think this particular usage would still want some buy in > > from the mm folk and at least Dennis (the percpu allocator > > maintainer), but one has to start somewhere. There were 2 different > > patchsets posted to move rss counters away from the current pcpu > > scheme, but both had different tradeoffs and ultimately died off. > > > > Should someone(tm) commit to sorting this out, I'll handle the percpu > > thing. There are some other tweaks warranted here (e.g., depessimizing > > the rss counter validation loop at exit). > > > > So what do you think? > > I'd love to take the project and work on it, it makes sense to revive > the destructor feature if that turns out to be beneficial. > > I'll do that the slab part. Cool, thanks. --=20 Mateusz Guzik