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 C4CC4C28B2E for ; Wed, 12 Mar 2025 10:33:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5B5D9280002; Wed, 12 Mar 2025 06:33:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 53EF1280001; Wed, 12 Mar 2025 06:33:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3E0AB280002; Wed, 12 Mar 2025 06:33:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 1D85D280001 for ; Wed, 12 Mar 2025 06:33:25 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 246F5140E81 for ; Wed, 12 Mar 2025 10:33:25 +0000 (UTC) X-FDA: 83212537170.08.11BF061 Received: from mail-ed1-f52.google.com (mail-ed1-f52.google.com [209.85.208.52]) by imf28.hostedemail.com (Postfix) with ESMTP id 5DEE2C0010 for ; Wed, 12 Mar 2025 10:33:23 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="iTZ/2PID"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf28.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.208.52 as permitted sender) smtp.mailfrom=mjguzik@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741775603; a=rsa-sha256; cv=none; b=gmfeAPaTNzY1Uqj2Mw4hgNlU40A3ZskTGRHOdjwONW1a8EcHK19geAiDGP0B56U7T0pGUZ hWXWU/UFKysQA+QjDI0EeJb6gZWNuZydP7C9kWuUEMDq2+6kYILHBROBx2jr8ubejM4Bny okrlEneVAlsS5NWh/WQ/mRmJQmHUyBk= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="iTZ/2PID"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf28.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.208.52 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=1741775603; 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:in-reply-to: references:dkim-signature; bh=IhH6HWJZC/8k2clhbagZ74zsA86O/+CwoIOwGRTQnvM=; b=Auim9hZAgINqBPf2SVsNK7zWCpDUI0ODK+cOo+A72ioAAhCBtrMm7W4HlOcd2K/Y6tA4HK XFiYmI8/ZVK2ipsahjkB0iQtrwHg31mMBen32ibq7Gg8vUFXDNqCQt4p62enp8xG2wEHIV M5gfouJsH6NjkCzVHgi0cvHXsNJyAeU= Received: by mail-ed1-f52.google.com with SMTP id 4fb4d7f45d1cf-5e033c2f106so7437158a12.3 for ; Wed, 12 Mar 2025 03:33:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741775601; x=1742380401; darn=kvack.org; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=IhH6HWJZC/8k2clhbagZ74zsA86O/+CwoIOwGRTQnvM=; b=iTZ/2PIDwQKiZRucKzJLY/I+eLMue3hJGNyj0MTIMgaExREmxNTuUh4krxgxRGllte BLO451LMq/DDmZrJDoy6Pj+iRMDha4VBmyoO0hqNUmsqJvcAUXyLcyRf6YTxNuwi/FhA E98tI2er1koh4yme16v4irUX9GhnLZdp0fVx7kD3spdJsRosBaoUDofWe6jFlVfPEKAt G+LYuToiXp0szM1QTbwCHDNyI+MaNzxi0p9lyKW1SxdhnlyEOOMFWXmWleQUFoD0ADUy ndPFNZHlBOkC58Knk5rzadODhX1/6SJUdxZxizmqUfAtEORRyhIfpSYNpIT8AEs3Rsq0 6BHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741775601; x=1742380401; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=IhH6HWJZC/8k2clhbagZ74zsA86O/+CwoIOwGRTQnvM=; b=Ixg2MH8j5dO7prkwUhVl/UELQ5vD6TwCXwpGeLHFJ2Tb8/9AlFoMKun0ZyVmOsGOfI ABCCu0pBunDDgmuajFHjXljFi2l/L0d1tijEFn4DCMuEsVOsXwAfrJqlA+2X027i/rmX 1f6YqxWL4Ng/D3Hosnfp0mHq1ODRsbClCmL3alMTnwyrmWH7Rf1UYvC6Nn25Zz7Ila9+ jl5lw8EI+FWFz0HR/W5fUE4HZjIqvX4EoYDo42ej6Xq2038j18oLy7SOH79y5GZPetiM ouHdgSP4ssdfBqqlAoui+ZPuf+4zKDO73abyN15Ov78dg99BioOHRvqadA1bG+sl/rao XCHw== X-Gm-Message-State: AOJu0YxvMRTlL8urscvZDC8ky75nPUsoQXkl8e9e9rCC0RYBsCZE+5RK tNCzWD+tiJyRQ01+QI72YHHoCjNn2kfYVz4WJ+G/ZJI2j1gpolSRJDu45qLQLUK2r3iz0uaH3GM zz954CdZ9s+u3vrG6c2VYr0lRD8M= X-Gm-Gg: ASbGncuEmPU6HuxpYn6h4t0/5fT8dlDkq4HrZkiguzXbAnH2JrnTgctK7et8375IZgO mlwhTfkeVrDdfPQrQMiQvXMQ6UpyIgxXO8w+EsCoQ0/cNz1ssehh6tD3xSCv4G3GUwl8P6l4c+0 wqXPHWmHUQHEbmF29YKEgNrFG9PQ== X-Google-Smtp-Source: AGHT+IHlW1xMpQytpG/j/Ee2Mx5a6+Aa49z47Hrr7Mh+bv+vC/+7ToERboajLDuM5J6Vsx2Qvinx6sPX4jjNsDx9dg4= X-Received: by 2002:a17:906:c4d5:b0:abf:5f3c:58e7 with SMTP id a640c23a62f3a-ac2525ad41fmr342039266b.3.1741775601212; Wed, 12 Mar 2025 03:33:21 -0700 (PDT) MIME-Version: 1.0 From: Mateusz Guzik Date: Wed, 12 Mar 2025 11:33:09 +0100 X-Gm-Features: AQ5f1Jp7uqB6L9mf8D74w67ZFUdQTv11hay3515ITv9Pmj7oBvPwfg8ouT8xe_Q Message-ID: Subject: a case for a destructor for slub: mm_struct To: Vlastimil Babka , Hyeonggon Yoo <42.hyeyoo@gmail.com> Cc: linux-mm , Dennis Zhou Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Queue-Id: 5DEE2C0010 X-Rspamd-Server: rspam05 X-Stat-Signature: kqkgauq6nkiq7gjq8aktp7is6gb5wxsw X-HE-Tag: 1741775603-130021 X-HE-Meta: U2FsdGVkX18J2E51dT7paLWbI2S4cd2xP+HcDQ4QpVbO0kpEUa3Ao+PCXv15I31BqxRYAFhkXrQDGy2DjJ291w7Q81lEhWusr4GNXVDS6jomQGpfXCDbM1ih2d0/SLXX2heAfWE18GJuP6c401WIMMpTGduNQ+GSC60aHP+m7ZBuepoLmao7TxwncxT3J2bGMKiJSBHB/xteb27k1sNgpvJkcwDxV8GQwLoPQZ0NGVlvvr39aeU/psbiha8NV9VI1uPk5y2YB3Iiodh5YXG4Xb/FmtSOa9QSXSo6qma4n3xErtJyyk1o7CI8XrsznkxfznADZTMVyZxEessOHZr546r6w/0m8gIorvOh7WTCxrYNaRMjnFSQn0gQiOe2DC04WqWfv70a41C59LSPlH0we08Bq9qQ+kW8Nu9GvobJHHs539HhXhGOo5d4CKkzLgPa/HgJDFiqUR9/iSHtpdiyPvBKz3L2KD+7G1CsgbAejy2+QbX7ddPBxw7b4z2LjN5yVvNoYR9nrs1xl+6E2TGpbjV8q20N++yhayvf4pP6trZ96qKw0awD9+C5YN6fs2h/O352RpW2oYBoaAZan4ukgNQLEah8cuZXfTwfUL15hRJnbCSW2/XYKwCwkSYOpI+lYZhlZCABmtDYTj6m6GlqzkvxItBT+ATqvAYEpeXtaBLXqC/HqNfJEVTw/NFQad/2QlKZBMNPJ97D+mSWCGVgXDhjlfycOPFcKYmno4iOC3/jE7eqAgucxAOgGo3DtPzPX+4Zj/02W1HnVGYGV0eL5RbAlDUwL15rW/zSxoz9XEZhRc4zM/6HgUP5y32d5hoIy1t/P8US5/eiapI9PyurEPDCKHvxHtQlm9bqdJh5MtQRt8zLlif9TNnQqEyGGOFW/J0XRnwoqCCBPVyb7oVgP4WMqc3XlNwe+jQo8IbdN2wcxtwUpPhq9G7RgaXAXk09BQocEdqd2vpnNMZL6dq K/0xiDSr 1cju5WTlLdvbYwiTmJjq1PAVY6RMNJ+qsmDMyjMNHf8A3sXZh4K40pIGczabhiejv7YMyeYZueWJHDt3eYk3OXxnaHR+08YlRSv0ZkVR+W1wTAygMY+9WS5rA/10diJOgRXUH/R4wdNYwhsHSc4+WFRLORhJt6UlJFJSxqEdcA2maaveuQfB6i9IZJtiZEBplEFAvm8msFQXHilcbhQsEdYDbw+QblEt7JhTXdMueP8bvb/fgnCesDXRSfM1PdWswRRhnOzYGqvdsSXf/tDJ6bt7tfYOKkJ7QlYgILt8l7LSdhL+LbIsgc+Mq2RIH1YvYFZVoPIARev3Tyn9i3DYkFk87uMfxPzJ3S+4ytwpXmjKiezyG2BHJQvHvB8ZhcKDSf85lXlp1DgVVPRG6KSXCUKOhli4CebK7X+BLnuAK7D/YL2yW3j+tFuNXLzd9S680e7SoEm2jJaJuO7T7tsSK2BVt5YhddgMnByBQ21/kAlCttWXOTUcJQMPML4sehGBO+gtbZhlSv4RG57c= X-Bogosity: Ham, tests=bogofilter, spamicity=0.002482, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: I'm looking for someone(tm) willing to implement a destructor for slub. Currently SLUB only supports a constructor, a callback to use when first creating an object, but there is no matching callback for getting rid of it. The pair would come in handy when a frequently allocated and freed object performs the same expensive work each time. The specific usage I have in mind is mm_struct -- it gets allocated on both each fork and exec and suffers global serialization several times. The primary thing I'm looking to handle this way is cid and percpu counter allocation, both going to down to the percpu allocator which only has a global lock. The problem is exacerbated as it happens back-to-back, so that's 4 acquires per lifetime cycle (alloc and free). There is other expensive work which can also be modified this way. I recognize something like this would pose a tradeoff in terms of memory usage, but I don't believe it's a big deal. If you have a mm_struct hanging out, you are going to need to have the percpu memory up for grabs to make any use of it anyway. Granted, there may be spurious mm_struct's hanging out and eating pcpu resources. Something can be added to reclaim those by the pcpu allocator. 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. 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? In order to bench yourself, you can grab code from here: http://apollo.backplane.com/DFlyMisc/doexec.c $ cc -static -O2 -o static-doexec doexec.c $ ./static-doexec $(nproc) I check spinlock problems with: bpftrace -e 'kprobe:__pv_queued_spin_lock_slowpath { @[kstack()] = count(); }' -- Mateusz Guzik