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 85907C282EC for ; Mon, 17 Mar 2025 09:17:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3D4D6280002; Mon, 17 Mar 2025 05:17:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 35BCD280001; Mon, 17 Mar 2025 05:17:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1B29B280002; Mon, 17 Mar 2025 05:17:27 -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 EBD7D280001 for ; Mon, 17 Mar 2025 05:17:26 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id E8504C1A6F for ; Mon, 17 Mar 2025 09:17:26 +0000 (UTC) X-FDA: 83230489692.28.3C12144 Received: from mail-ed1-f52.google.com (mail-ed1-f52.google.com [209.85.208.52]) by imf28.hostedemail.com (Postfix) with ESMTP id E1F90C0006 for ; Mon, 17 Mar 2025 09:17:24 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=bynAvDNi; spf=pass (imf28.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.208.52 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=1742203045; 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=Z42RLDyCr+mUssEUY1P0zG8IYY5oy4JN30WjazLqL1k=; b=jN8aU9aJair6SPZRepOIvFKDR7QK0Q01dooNPdAShU26Nl131q5C6jJbwp6bmyTQB3plAw UAk/vIrgXA15DllctVIYWhMi4zCMziuj74ZSvVrl0grccpH7pkHIDVshNroK7CEy3sl69p Ov3aYISP0S57fKTs5FsxXLJ/C2ruM2w= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1742203045; a=rsa-sha256; cv=none; b=IgLZiUgoW8LFHtJ6JnnPhgw7xlxjw4bEUh3qn5U29JZmdPRFPb1FQ44HBxNLQgbbRmZ7It TEdcMBRiOW+a6ASKXmVJQQXc84LUYePwZgTXcTQpeb7cL9adm8dSUW1DJxEu7gqy5Q2msr HBK2iVDlcbEI/QsYKKt8m+t4/yynVxU= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=bynAvDNi; spf=pass (imf28.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.208.52 as permitted sender) smtp.mailfrom=mjguzik@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ed1-f52.google.com with SMTP id 4fb4d7f45d1cf-5e5b6f3025dso6014338a12.1 for ; Mon, 17 Mar 2025 02:17:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742203043; x=1742807843; 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=Z42RLDyCr+mUssEUY1P0zG8IYY5oy4JN30WjazLqL1k=; b=bynAvDNiciRkrg9jIOEQvbkO9lD8Nw9CYxASB5Bd1F5VNiFuGO7WHGuHRtcc92J7o/ wy2CA/t/JzyNdqWIqVJpZ9W2K3bZJ4Egah4fYP6K4TOt+7nZOinkNGrxLsB9ToCHwZNe qDuYNLf3RD3PmI0JPeI054IqnlFjOEWEfNlLHqDnoAREOP0QnRaIaNvXukU8UsgpDbLj DBFgYMH3DWrmPHLlzgA8pDV+aJZ8aXMg1l+Cz4DDmuk7keFGp9HiLOXYkW6DSzm6haN3 rKTPAjpeBWam9DdPYE7qxK0v6ij9YfFsfH8g9GFcSo+HW7VPErTTbYD/laNZodDNECdC VhJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742203043; x=1742807843; 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=Z42RLDyCr+mUssEUY1P0zG8IYY5oy4JN30WjazLqL1k=; b=nIk3FdNT1hvdClYoxYsLvA39d6mhTN+2Y57u94nyDvQXgxrlMuk6747dayoeI8ybct 3br4VhdVEoUFI/qp1oNa5GtmA9o4ccOxI4iDoFDDm/00McGyiaQYU4lYNoKXzzsemz18 2ViMCfWcxQ2jTDnKg6g1vgEs4zZoucO8kkyGAQeDB4j0ag7WRbSE+yRD/X2QUka5hFiU wEQsiZ3Hu7oDLXoJFAWVtlcATvohXST1oTIY1FyntDCbL2pzg8TRgY9ZO8PBR+qygI+m Jp8Jwf2GFSFnYwekUnoUAy7GmK3oya7q8iZ0tNN2eCIi6isTb1/OKY410y2gO5YoNHfA Qw4A== X-Forwarded-Encrypted: i=1; AJvYcCWftxEG4zgyIB7LwP3ar0TlPXBKnpXrAvai+6DpKneKJ+e3OhGWAaBiOthDZ6wOUwRo3EH7xjVr/A==@kvack.org X-Gm-Message-State: AOJu0YwCRIh+ffzIqnumiRDeaS7qG/LtZA6UaBM6SR5TbHF5U6iDhZtD UPXKbv43tHVuchsswg1UuGd/ah8r9f1tgrL/LwVBCQu9XMTTKwUUNzhTCoSn/RHbrDYtwucdG++ plO0zRIQFDR1mKdL4c1KOmigT8I8= X-Gm-Gg: ASbGncsoYgM/yo0u846fbPbxbe7n9jMBS3zM6CSSKnhf15oyjmfuSAlnm11Dg3HxxEQ MURSu9Eo6fbF6zDQbtRd2iwlHxL26mxLt6ZtTTiC+w5YP9DjmLIt3JzVDajY196/EVjv0rmaRYC F3Hp5pOQEl7tS8uCg5bms4C61DNg== X-Google-Smtp-Source: AGHT+IHOCXF21uo++O2oU189j3TYw8xjpMJFG5AlkcYNwO7m1HGExa1mXqOSS5Fuj3FTtTpBdJuNNINrpnlPPovP3Uw= X-Received: by 2002:a05:6402:34c9:b0:5e5:9a2b:167a with SMTP id 4fb4d7f45d1cf-5e89fa5108amr9754769a12.17.1742203043063; Mon, 17 Mar 2025 02:17:23 -0700 (PDT) MIME-Version: 1.0 References: <4aa49f49-baec-4ef6-87c7-effd5a1dc5eb@suse.cz> In-Reply-To: <4aa49f49-baec-4ef6-87c7-effd5a1dc5eb@suse.cz> From: Mateusz Guzik Date: Mon, 17 Mar 2025 10:17:11 +0100 X-Gm-Features: AQ5f1JqAbSP0xxjBJ3wv2RGObbUwY5Hb6PdnKlovJ2CFXyERkDIUCBJ7rruR3f4 Message-ID: Subject: Re: a case for a destructor for slub: mm_struct To: Vlastimil Babka Cc: Harry Yoo , 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: rspam11 X-Rspamd-Queue-Id: E1F90C0006 X-Stat-Signature: dctdyuu7aidh7799aije1rs4shuixmjx X-HE-Tag: 1742203044-89632 X-HE-Meta: U2FsdGVkX1+A+LbnEJwZ1zdBSxplzKAEqFFpEnPNgugUDjfVkTUL+5nXoKe2txvofHvCl8LW07DHpy7qKSZZUdb2lbe4RRRmuhvHTQZFqTowHgnY5tKFxkwzMqMT8VS7iYWH3V6IWNw4uKiEp0O6fT4VQ1mg2HkmkzySXPYDBmcW1pRmKilZ9y9J+dj14ZPWQayjq5iTQgu57ojiQ2aEfe4ApHz8hjQxnWS05c3J6qwl/Rgloj12q4tQUZJKmic0he9EmfuRCxKHAxI4sbt4DY+PETdH7510rmQkot55WiFyJ2N3PcDqBibN3sFoiLcUBmBA0u3/UnC9A9soDdyIR179B2xJUGvak9I1MYpEFU1gQjneuZpiMLq8496OpB3uBBekji+rj+/uRPx8F2TJO6HQLgD1YkJrk7PBPeBPsL3+PCXeLi5KRvq/YMykXz+jo61SxAwdu6hXz6buDFLHohkUOFLLdiw0OtZYcnOYPIsfSRIJ8ovFRyaoKhtWbcBHkoveU9C8vrG2o12gUIzqzmMsZ9v1vEOYWeiqr+cts5xikD0zQU9I5nKYAlv3ALrpga0JnHGBrmYomUhi63HdanJcwLFbxwAOSQoU7daCTCKls9AukeZxZrRDAXe05/4bGMZeowmcOqNgaGWrhKavTCSBl1/1cMELwcM6Wci4ermT/IZFA7samcnjFXvuE5286VnlGb/0kpHG9apmPA6CYO9tffVerPt0FTFyHzFs9W2Oyb4znDjHzzahvhdgvLPDONbRXJ3fm65vSwMjV6kHVX1OPUkujyv8wQ4j3rOjNBks1mzbMr+enKymIENcJgEP/mXSeIpkCBw0aEB54h2NfahWeKLpas2GGM0ZX0Jsuq4dVM/4Rcc24pvLU0Fx8E4SUjTnV+ptvXjevySDeW8GtjiwlXHSp7uhVNgrA62GV3yLirzpKubcAa602IH8bkSBVV3AcbHrdv+oCDoRH2U lLqlUP7x 9jsbYd3FkokX3BTyDF0iCAwJW5m5CEAiEG8WFzQAuOkuDhKvRanlBniLpL+TWU8rDGW2mp8/cy21R2c+m7xLt7xHXNY1kHKeRg/cyl7ZjqBAAJQYHuV1NE8EaA7lYpTnz7RClj0BFzz2Q+EtvboEchdjm9J2oBXGWYDtAXJhw6SktQFdO4tEbcZSY+THU8g+0YMEtFXVAMluqlmCTeiASfDhKcTVkA0stMgomXBvD3Bv+sNFAKGN6LCT8nwWuoRNThS1zkrB91LgXrOzd/XRnakiLUBhlztMs0J4fqB71BgFfIA2PGymUIl6FPY0Uf8mjyICqzwS9BAv1+HREGjSPBbcQs3ZBzBIKR8MBLtmhF4HvSxF19a2ra7yFic5H04edjXkryu/FYl6Z5i0/Qe6fJJ2eEWdvF59hx1XpMpNL4W3lIsXzy8A3V3jj0GwWNOZMwh7QPfgzFP/u9DY= 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 Mon, Mar 17, 2025 at 10:02=E2=80=AFAM Vlastimil Babka w= rote: > > On 3/17/25 06:42, Harry Yoo wrote: > > On Fri, Mar 14, 2025 at 01:32:16PM +0100, Mateusz Guzik wrote: > >> > 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 > > > > If we allow reclaiming per-cpu stuff only biut do not reclaim > > the slab object that contains it... > > > > Does that mean the users of the cache need to check if the percpu > > memory has been reclaimed and if so, should call init routines (e.g., > > mm_init())? > > That sounds like something we'd better avoid? Think it would need to impl= y > some locking between the shrinker and slab allocator so it doesn't hand o= ut > a mm_struct where its percpu memory is reclaimed. > > I hope it's enough if we're able to shrink what slab allocator has cached= in > per-cpu (partial) slabs, there's already flushing of that from e.g. sysfs > but can't recall if there's a shrinker. Of course there will always be fr= ee > mm_struct objects in partially full slabs due to fragmentation, but I dou= bt > we'd need to worry specifically about the percpu memory those "own". My preference here is that a shrinker will just whack some mm_struct objects like it would normally happen during memory reclaim. However, should that be difficult to achieve, whacking just the per-cpu areas is perfectly doable at an added cost at allocation time -- you "claim" the obj with an atomic op. After that it is illegal to whack percpu areas from under you and if they are already missing, you just allocate them. Getting here is not ideal and preferably avoided in favor of whacking the entire struct, but it can be done with minor hacks. --=20 Mateusz Guzik