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 2828CC28B2E for ; Thu, 13 Mar 2025 11:26:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 501BC280003; Thu, 13 Mar 2025 07:26:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4AFF7280001; Thu, 13 Mar 2025 07:26:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3781F280003; Thu, 13 Mar 2025 07:26:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 1B7FF280001 for ; Thu, 13 Mar 2025 07:26:10 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id D700E1CD1A5 for ; Thu, 13 Mar 2025 11:26:09 +0000 (UTC) X-FDA: 83216298858.21.2D14605 Received: from mail-ej1-f48.google.com (mail-ej1-f48.google.com [209.85.218.48]) by imf24.hostedemail.com (Postfix) with ESMTP id D9F5B18000A for ; Thu, 13 Mar 2025 11:26:07 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=WAUc02T4; spf=pass (imf24.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.218.48 as permitted sender) smtp.mailfrom=mjguzik@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=1741865168; 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=ZpF6Dwpkgmi2PZSmZIt9FybCLnXoc2ufN/4m722ak94=; b=nndOPwpc8t9/gI08S8ltimP3VvSFeapy/a8EeCEOkls6bb7QNTmNGwwl2EaREyzAifgoHp /HXKTap+/V+maTaCpv1az4DwrnRal+L40UvDzvnHGfkLqA+d920/o7Swyt8VonrK1tYYOB R+8FR7TATgFoEhKtG9z+Icv0/6q3hOw= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741865168; a=rsa-sha256; cv=none; b=eCTVFZ2/ICV7KUf9Y0DIg3yzYtkhqHyAbLafZzm/5Serkt8/hz4LJRDRyYNWMsV8viHw2r jpctZpOI/8usO3RBmN9IwOhnkK3/N4YaWvyA288vre2hmndNMfd3gE0SNyec5NgQpQ1tLN fhq+kf+9Za02qYl0iwagUL1TaQUtGB4= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=WAUc02T4; spf=pass (imf24.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.218.48 as permitted sender) smtp.mailfrom=mjguzik@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ej1-f48.google.com with SMTP id a640c23a62f3a-ac25520a289so155327866b.3 for ; Thu, 13 Mar 2025 04:26:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741865166; x=1742469966; 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=ZpF6Dwpkgmi2PZSmZIt9FybCLnXoc2ufN/4m722ak94=; b=WAUc02T4VG1NVSAO2rC7RMAPsBgvU24PfFXo/0CfjCuqaMUx/5ctBEj3zRIbOeXNiL 1NgOKbNMfEPfEVHWisAMBXvpyTb9S3I16VCFjUwKId7LI9OGFn/RjNnto1RQRu1tPUHc mDckFNzkkGP1fKFxnUOuG+O/L1i1jYkqiyEw1xCNGhL43093eo9m+KECpVk3X8fKhvag L7PN1WXrbCHez9ezMQ+68N2JVVUQeSY4rUx5XKyLx8tetVeJRYku53vnUR+6DVQ1/bcL FTGNNvebc1GqUEdEmCErnZGoC1Ti22aYhO/E6ysKzAt4BhSOum1/yYDkt5k10sSQiHbf J/aA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741865166; x=1742469966; 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=ZpF6Dwpkgmi2PZSmZIt9FybCLnXoc2ufN/4m722ak94=; b=Z0DgZADXMdbuqHqR8FZI1cndHLT8pA2U3PiDNLJ78DCGWT8p11k4HsxJ6iJNjZJ3Fr 8WgQHnv2o+k2dwTvOJqZ4JsWFmUS7k6coG4gH3g30098DkIdeLfojqeVIi4ecP8yrNoa hoC5ltEc0Y3KMDu2FK5XgQIKey5+2wPEzpVRO/jsgIIJ49dZMvH7lLg5IzhypM8MAJ5g TnTR3PujMX47/iRwaMA9MR4453ATT90Xkgws5+rNscs1/Cp5XRc0T/PG1ovspICd0bSt utTXIcWmarg79AI1sD6z3SIxkKZ6KE2784mdmljySBjoI3P0OG5p+XveoDuLhsqdPXRM UOng== X-Forwarded-Encrypted: i=1; AJvYcCXGfNBebSvGYeO04PkBQJwRlbivMunFJhDZHJeEOvLX4+KYQdbpPTZl2vBOj104qfxDFMoWYPpVfA==@kvack.org X-Gm-Message-State: AOJu0Yz3+Y6zFUo/93Nvl+jxZd35fbCEyJsKEF10TDgmtFKkYXkbqAii 7Nictx0AhPxr+p7KHN6lw5It2S4afFF3d8fZq60VgFeVIVeMdGF94dX6xv0RU4OZihQWgbQbUAk sxhbR2FNDakqqMri5juOVSM6OcdM= X-Gm-Gg: ASbGncsQoOKs4bi/xYmmcNT/PZcyVx0KHlgV7Jdhc2KAD/0tW5zC/mVZE/z2xiGmx+h wW52j3S+YIiSMS+wwslwpqvg5C/6+68SoFWAl89esRynNhTs/GCrkgTaisrOHk7gFAwOZ9cSB1W wSTBDDCI7ah1Gjd3JB3UxXQHWzKg== X-Google-Smtp-Source: AGHT+IEhpi0wvp89TcSFXmvcqsN/a3sjM6suh+MSmzt2v7OWqD1jB5gdwkJadalV7+Uf9unA+pq4/M2/CjF8H/tbKbY= X-Received: by 2002:a17:907:1b2a:b0:ac1:e6b9:57ce with SMTP id a640c23a62f3a-ac2525e07b9mr3133718666b.7.1741865166138; Thu, 13 Mar 2025 04:26:06 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Mateusz Guzik Date: Thu, 13 Mar 2025 12:25:54 +0100 X-Gm-Features: AQ5f1JqsRHT1YD3p8QfVXv6JZPPbGC68UeF6YWLNgjaJlGkrPI-dF9N__8J5i3w 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-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: D9F5B18000A X-Stat-Signature: btkd9pjqkoes1d591zbfpi1ohc94es1m X-HE-Tag: 1741865167-268397 X-HE-Meta: U2FsdGVkX19EV3SepvK7a8hnqpVD3xd2Lk4dswaRwuNlPf1V9y6Zi3i1hPVNVlcATWI2+i6swEcZ//DMoObopdfJmSAgOGAWSBDGUh2vCRs+oAtifCspW+Fkr30gLC6+PRp0vTHlrLxJ0jK6BV2oq1j6eXP4EAm0sXjyAJ+SKzVVSzxbnawzU7dIFh/0m/5Tae/nA0diCnnqHRlX6Mvuz72T2SLWiZde0vLRWWmSTFk7ESAjDWuqjV+a5gSXl22ewDHuXouoVCqf42bsK8Ncfd3L4XX3jKVThoK1mmx4g4lA7uXxFqFKFRtO5F2LlySHu1WzfFTfcy4LAshPh7r6XpsquhmLuuzOJRNpoS/wa60QGbv0sZ+d3+lfzHR3qj8uOHoOFi/hYj79HONkHu6Q5DXsPSmoYzOLZ7CXZhUoQkdZyFe6+yXxuEviTZmpsjDNmsWdSXfySaX/HznrIq6KbtKVbDR5dv5bMppijDR5H0E//xnwbIzwtLTTCkC2viUNfIffYUsH1VvXOrZIPB733oT1Wdi5rXqBlDUipwEj+MQYKumEpfIb6XRUzEyL8kIEVsdJAfL1amHbsxSVOf7Y1/GoGbN92t/lREWl02GNmj01tGwXivMvxGgfHNi2/5V8APASonscIJouyoerkpk6qHoflDBmpFkKXX80dZYeQnioRUvgxb/WzV0ZFALFHu1ZdZUep2mNN8mZbXF0z8PmhHH3buO+X3LwWhgX4kzulJ96zMTuPbIhpZ0zxxoXAkuZqfMKH90vaMGA8lm4Z9mi4ZU/t62qPqLsH0dyejC0Wl1AG/HdNtncnry+3YyddRpgBt++KtS4VGjZVR2J8NNpqPClmp/q+oVrlY2i0UuuKZRP/kb333TwuUgXQY73fkvxsNwzomsFBNvzlSv1uYZYKdECdTpq/av1+qU3GHSH2VqH/1cq61ITNFEhprTRf1NaTJdWVPoNR4c4w0XJSy6 2GgDcURV lVhEnBdHqDLNCScanuJmxYclfwKX6uWGd4s2PHD+paD6DXVuWTIZI+cMz7lsQu5A4A1DPLeynT5O60F/O6iISRr6b7Ygld5h8lhzN3GQhBsc/9s6cU0FQHdbzxiBVqU7p+fiwwO7gq/763Rtp177kRv1qCyFCJ+iR0ioGHZidaV0CnEnw3wVW9IadD+NNp1XiSEQiW2DmsjD8cTrUb1PCFCQpv1qcdneuvw3z+SrXso4KpDPhAz1E6qbts1reQ7aScg2kEwlSUuJKWmtjxTSDx8E8UDY/4kdSPzMfxA1oDXvFg6tQmL+J4eUE69SPD0m+sKRFKWw4MjZ8KDCkhGPi3dYb0xhv7BkhGWH7m8m+huKGkDn1Ab1Tgz+cI89f8uPVgQGx5UX0wxLuNurK5HWrq5Y6VwJxXkQT5guIJy+Ixz7E+wM/+ZgTc6Vh6brc4qBOjga1J0GHs4CWT3gMj9bbRI2NUWyB6SGhMega X-Bogosity: Ham, tests=bogofilter, spamicity=0.000005, 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 12:23=E2=80=AFPM Mateusz Guzik = wrote: geez, my spelling today is really off even by my own "standard" > > On Thu, Mar 13, 2025 at 9:59=E2=80=AFAM Harry Yoo = wrote: > > > 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. Instead, this could be patched to let mm hang out on the list and have iterations of said list skip it as needed. > > > > there may be spurious mm_struct's hanging out and eating pcpu resourc= es. > > > 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. new pages > > 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 b= e > > > 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., depessimizin= g > > > 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. > > -- > Mateusz Guzik --=20 Mateusz Guzik