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 B1672C282EC for ; Fri, 14 Mar 2025 12:32:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A8DCF280002; Fri, 14 Mar 2025 08:32:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A3C75280001; Fri, 14 Mar 2025 08:32:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 904F8280002; Fri, 14 Mar 2025 08:32:33 -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 73CE6280001 for ; Fri, 14 Mar 2025 08:32:33 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 4604181046 for ; Fri, 14 Mar 2025 12:32:33 +0000 (UTC) X-FDA: 83220094986.24.F385785 Received: from mail-ej1-f51.google.com (mail-ej1-f51.google.com [209.85.218.51]) by imf06.hostedemail.com (Postfix) with ESMTP id 4D15D180006 for ; Fri, 14 Mar 2025 12:32:31 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=YG7rvN+h; spf=pass (imf06.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.218.51 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=1741955551; 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=+xIshTMMQ1QhVAER1HFKAMguYdelZlsv/yHPAO1+Va4=; b=N3TUo7mtZG+kKLyY0I4+lYT18Kc6N35P6/aQ535+xbm0X75JIVvRsrpG8x4qPf7on8gUpW xGqMWSh5uTn7szEJM+zzZ0wvUAbm6HjPHaeHM3gJpt5AwIrt8rlpzZaIXoyGYiPSAao38K aWqDoMtczxO5s75ANs606VmTHjNHmjs= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=YG7rvN+h; spf=pass (imf06.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.218.51 as permitted sender) smtp.mailfrom=mjguzik@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741955551; a=rsa-sha256; cv=none; b=STtGSvMAb/a/7LWnk0PDlXR8RT5BNkIqb/B/j1idUXlpjhZ1OGs4xZC5JcA4cx/WF4wNVl 5pUqzDC4j7PqCNIzYi75be+12mIgbfRGXj7okRbC1O1PSaiGDWax/p3RbHjcfkM0AowzXA 5OssI6UVuu16XgZPz4q05MoLLAehJ58= Received: by mail-ej1-f51.google.com with SMTP id a640c23a62f3a-ac29fd22163so346276666b.3 for ; Fri, 14 Mar 2025 05:32:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741955550; x=1742560350; 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=+xIshTMMQ1QhVAER1HFKAMguYdelZlsv/yHPAO1+Va4=; b=YG7rvN+hW7zJkVMNeKCdq5V8ljGzLbDgJ4WO/TR14n9FGW9kmSm1/zk5C8maCy5ZHr YLatuljTjEV4pNKxIyGFHV+m72HghG524x94iIqZ9HkLgVIH9JGhhF/suP95lDCW8GKB AiTdVLfXk3xGvGNr0VN76yI2JLR+c2gNYGLWmxtIFE7Sir64p+0wxrw904yx1LXvICF0 jUbHeLUasEV4RW+OIgCLkrqFs6qTpyXB4Pv/2feYiB9mE9XjEETFGo/76p7ekmgrbxQS wyNW/WSkZmPLNHu3JRV1JuZmMLmCL19zcT/GP3WHlv9fc7RlYWh6I+JXcFZKVs+bDwCW IOjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741955550; x=1742560350; 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=+xIshTMMQ1QhVAER1HFKAMguYdelZlsv/yHPAO1+Va4=; b=EJ+ZKO85seL11itKGIKNHPk97Qp3unQy2Iic10VhrEEW9MZQ1m5ImE/oQFPjjqZtaF M0/wpMq8IpI17khKMs8Q8yA38DA//su61D+GRTUkSPqFrJwh13ElPFGENSbGD+ywAxoG 3q5HHMSHXLdGQSwoNkqdzPr9hde63Se17rXQkmfmhUGZHT44vbK17BjWcg97GMqBE7BJ a2ZswR5lIpJ56D/88f/fd/oX4zvvQYxSTpJmf7zsDUMMnGElAS3TIFiT2tHvqnJqpQ+L FaoKj7yvEgBRTbdkqjEzZvEWrH/63CDFOF7OHEIkCZJaj13/btn5kDWiHQiuxiBTt++C pqqg== X-Forwarded-Encrypted: i=1; AJvYcCVVsWLfpw75MAIWIJ2GW9aPL//yp+6KQ0ycVxATfhdT7DEkBoitOf2KCOpKuUOz0dYbQBL5bvoWRg==@kvack.org X-Gm-Message-State: AOJu0Yzg3ZtGWipS1lnOehicVDeLuCrqA08bCRZaZgZKJoqwmlF3g5Y/ TMwliZa4e8OK/WnAHR6wCHZuk9yKsF7NfH2kWecwLDbTC8tM4BB5/l5BipTL08On+qX0Ti0DBFb g44p2t+mHVWIztChUgI9LUyJALHY= X-Gm-Gg: ASbGncsjcZSAaYgUTXdIlMzHyQ+BwU7ho7Nag2HnRCXg9lbgcvlV3B7F6VISOyE2upo SMF0DEURwu4sQM/3uQ6F2atLb+k7XM4Yhrqv0J8l5K8dERpAy4KDurKrEPFti3PkBv7bEfueEiQ g61wDf6UXKeajTtFyTvnqh6o/bEA== X-Google-Smtp-Source: AGHT+IE5Rn3KNtdHVCpUOd+aZGOQdXHkPIixkALdbTzr9Lm4IaSv5TdoHhgg8ISfLuBgnhGms9mk7/EMdIA09NSMbRY= X-Received: by 2002:a17:907:c23:b0:ac2:c47c:8716 with SMTP id a640c23a62f3a-ac33030147cmr288935466b.28.1741955549369; Fri, 14 Mar 2025 05:32:29 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Mateusz Guzik Date: Fri, 14 Mar 2025 13:32:16 +0100 X-Gm-Features: AQ5f1JoTPKkgK0maqf9l-VuA2mtLRxJNv0U0XiSBJBOKFE7cypt2Sk4hvvHLs0Y 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-Queue-Id: 4D15D180006 X-Rspamd-Server: rspam03 X-Stat-Signature: hgka6wokgo83cthsjru39mnd5i9zodui X-HE-Tag: 1741955551-358056 X-HE-Meta: U2FsdGVkX19L4Vh7iowKNS3CHuVQFosql6c22SJyDoaESh66e58BHgAvqXBAbcVG1JtSlg10lICqCPMR6yd05AHJCSsu34wUo6Hhqn33DF5gvCEK5ei4xrcvjYkEbLthu3hkYYOzOPCJm1IFNkmSb29tFQN2ThJinFQan/wxK4BRWwpsRsaY5+27tGdaEviKn+KUueS7UV0YYdiga4XkrDEvuE4SF7n9pF/6pFDtDAxGpepPagxZZ2sa4ba8xnWxfMAm/smkfnSKJSbYsrwXw9d+8rNb/1TG2AiZrfOuE9bT8XgWtwCENyiGzPFx3NODlT9Y+QEU3/sgSE8KbZuGBE+dyxwUmsKTT4GPz/M7WtAcSoF9jz3vhjWojhGhSb5ZDEf1Ie/W0+F7QWN8DtN2GUWm/rjoF5uWaE1Gawx27eJtgwA2dKFR2NAmgrVCGiSDbr1CBzIcHLB5PXCFkpc5CQiEca1ZgoDzn8K3gg0zCAVKL9BuQu17/aavI9FOeh3GpX3uI0t4aeGG1qviavogdy57rY/2p6Fpmg3ddbUm5uNei5Qe5Z8YgZp2JD12/85M8Zlzq3A/aVC6XH1RZtEDqC00kFfbhd+hY/AVwUKWhjqaB4rXDLEHP1eLUNPXtxPkYQiLdnWlV+jPv9ImmUqHMLI4ZikOr248hFyaDU+PTHMz0VRJPipf/kRzDblZR4M52q+L7RpIt2YxS92OKkF91JXs1Z4sJNPKK8XxcQ957eR8tL1LQfhCYJh5trFWbxfIhfvmUGLzj6TqTiLkiASy6ZN4+j+aaCB+ZDQOYVl0R4+fBY9lRcglhLbHIsGc1j+G2IMdIgfN+UW9WH03bfp8QWyfQ2e/7cBRqyAGzAaSX1L9MpAqFG4BH/ueGuhP9p6fuVAm/5MD2geXOZkTruGamQNl+uunGm270fPiGtz3F0QSmTGAIgbvcUJjggLa7yzqy/8TwEA6DWr4TmhYFLr zVEWb6zt MQDaRDbjJeSbkQhheAdJZPVEZwe4zd3CIZ69z1P5zaZPYyUgJZ7+pA5S1S6Aqf/kP3XftE3qAsusFWrPip04de5fVGAGaFgWl9SKFZF+m5TAiSzC8ZSKhnLD1LpNXMAPzofMPtsp6TqjOvwTms7B5gysRQ3Ho/DeMBYMdu+8XGY5Rfmf4VZJr5yI6YSPNvLvvyIkJqv4Y8ln8wjq7C0oJmiWiiisdpKdi5JoASrFUt4bza5Q1QM0MsOmts+fQq6TzSHMbMezLGAdTLMmqZH2yrktcjPZwkT7mlquwUZQmNyP36eq1OSNkH8raYbZXqtkOJyQPZQTKjiXqgg2bP2pNcHr4vmMdY4RpgUA3eVsYsmB3Faj0K3ArlbmWkOwOuIK/ijASg84LBkhzw37CK+zD/NND5C0YryxvkdNcmD9ZNRIDR7xjQT/BiSnU5GPz6ckRb13dy32liZH2LdLMqRi86ZcRzdEXr7KrPjx1Oaw02y9LpzkdoWkLFWNZWeQpdx1/ob0/V3Cc+8R7xMqhu61YB+3XHoVV8QaSyrFSQGDKKwkB7XJC9lbDDxO+dg== 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 Fri, Mar 14, 2025 at 9:27=E2=80=AFAM Harry Yoo wr= ote: > > On Thu, Mar 13, 2025 at 12:23:55PM +0100, Mateusz Guzik wrote: > > 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. > > Okay, IIUC, you want to remove it from the list in the destructor > and not remove it from the list when freeing it, and the code iterating > over the list needs to verify whether it is still allocated. > > Would this be with SLAB_TYPESAFE_BY_RCU, or by taking a lock within > the destructor? > > The RFC patch [1] that removes the destructor states that "taking a spinl= ock > in a destructor is a bit risky since the slab allocators may run the > destructors anytime they decide a slab is no longer needed", > but I need to think a bit more about how risky that actually is. > > [1] https://lore.kernel.org/linux-kernel/Pine.LNX.4.64.0705101156190.1066= 3@schroedinger.engr.sgi.com/#t > It's a spinlock which disables interrupts around itself, so it should not be a problem. > > > > there may be spurious mm_struct's hanging out and eating pcpu resou= rces. > > > > 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. > > You mean reclaiming per-cpu objects along withthe slab objects that uses = them? > That sounds like a new slab shrinker for mm_struct? > at least the per-cpu thing, mm_struct itself optionally > > > > 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 o= n, > > > > 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 o= ne > > > 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. > > Hmm, but I think even a ctor/dtor pair that operations on one object at > a time requires changing the semantic of how the ctor works :'( > > For now the constructor is not expected to fail, but looking at > mm_init()... it can fail. There is no way to let slab allocator know > that it failed. > > Looks like some churn is needed anyway? > indeed, i did not realize it at the time, sorry :) I'm happy to split the churn and add some 'return 0;' myself. --=20 Mateusz Guzik