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 F0FA9C282EC for ; Mon, 17 Mar 2025 09:02:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1A8F3280002; Mon, 17 Mar 2025 05:02:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 158B8280001; Mon, 17 Mar 2025 05:02:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F3AAD280002; Mon, 17 Mar 2025 05:02:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id D609B280001 for ; Mon, 17 Mar 2025 05:02:52 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id AA5E381AC9 for ; Mon, 17 Mar 2025 09:02:53 +0000 (UTC) X-FDA: 83230453026.04.3E1FE51 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by imf17.hostedemail.com (Postfix) with ESMTP id 2CE9140004 for ; Mon, 17 Mar 2025 09:02:50 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=TjdUe7PO; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=wO3pi8fc; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=TjdUe7PO; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=wO3pi8fc; dmarc=none; spf=pass (imf17.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.131 as permitted sender) smtp.mailfrom=vbabka@suse.cz ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1742202171; a=rsa-sha256; cv=none; b=uRAos8wYRe7G1ZejI+ph+Ewx6XCC+ZhdSkqLUPQHp6CfpVW/MqTSJwl5Pwoe+zb9gp53kz O65eWSn92mMAJagzGmA6Iw8n+vHR5O0wjxPzhQ+CueKtbGg37Qgei/PWwaBqRMsDd0XY6y UteUeJjgitnx8SgAdwHxtbODxxRnbNw= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=TjdUe7PO; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=wO3pi8fc; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=TjdUe7PO; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=wO3pi8fc; dmarc=none; spf=pass (imf17.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.131 as permitted sender) smtp.mailfrom=vbabka@suse.cz ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1742202171; 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=B81lh/fXAk0zaRogm94V3cferUHvnzxAVHjn1w4Y2LI=; b=DQoVweYaKaBp7THeJVmksm4J7L80kXK2U2G3IILy/fykHbTX4TToCeR81aCg7mkc+2QBg/ k5tBJc1zZO/bm/M/o9lMIOKidf1i+yG2RaLiIwLxPTcZuLBurXHJFVPxWkO0aZFkJ5m27V Qk5FBiKv/hvFJJUbblkRwgISnILY3Ro= Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 3AF831F7E6; Mon, 17 Mar 2025 09:02:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1742202169; h=from:from:reply-to: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; bh=B81lh/fXAk0zaRogm94V3cferUHvnzxAVHjn1w4Y2LI=; b=TjdUe7PO31wKhwHdu/jbhY398+H5zKm8DsV2rbFko2B63mN8kjj9Tre0EBzVjoQ+IgCgEp e98BMg3WYYQybzc2BKjOQVmOVcLuCsmzkMKK+GPCUguL1+vZeuk6612mSbl0UFLMTdwdcF U3PXMLQctHHPMtGBGzcRhUCJR7iP5CQ= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1742202169; h=from:from:reply-to: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; bh=B81lh/fXAk0zaRogm94V3cferUHvnzxAVHjn1w4Y2LI=; b=wO3pi8fcEuEWrx4TjDZjIPZnxWygwCLRy/06v2aTGDBNUTyF12lclGr2Ry/9aZiX/8XVQl 4XVSEItEPNscGtAA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1742202169; h=from:from:reply-to: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; bh=B81lh/fXAk0zaRogm94V3cferUHvnzxAVHjn1w4Y2LI=; b=TjdUe7PO31wKhwHdu/jbhY398+H5zKm8DsV2rbFko2B63mN8kjj9Tre0EBzVjoQ+IgCgEp e98BMg3WYYQybzc2BKjOQVmOVcLuCsmzkMKK+GPCUguL1+vZeuk6612mSbl0UFLMTdwdcF U3PXMLQctHHPMtGBGzcRhUCJR7iP5CQ= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1742202169; h=from:from:reply-to: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; bh=B81lh/fXAk0zaRogm94V3cferUHvnzxAVHjn1w4Y2LI=; b=wO3pi8fcEuEWrx4TjDZjIPZnxWygwCLRy/06v2aTGDBNUTyF12lclGr2Ry/9aZiX/8XVQl 4XVSEItEPNscGtAA== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 23A73139D2; Mon, 17 Mar 2025 09:02:49 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id pl1mCDnl12fVBwAAD6G6ig (envelope-from ); Mon, 17 Mar 2025 09:02:49 +0000 Message-ID: <4aa49f49-baec-4ef6-87c7-effd5a1dc5eb@suse.cz> Date: Mon, 17 Mar 2025 10:02:48 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: a case for a destructor for slub: mm_struct To: Harry Yoo , Mateusz Guzik Cc: Hyeonggon Yoo <42.hyeyoo@gmail.com>, linux-mm , Dennis Zhou References: Content-Language: en-US From: Vlastimil Babka In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Action: no action X-Rspamd-Server: rspam07 X-Rspam-User: X-Stat-Signature: d7zsu8bxd5qhsstewrkonmp8k96cs8cr X-Rspamd-Queue-Id: 2CE9140004 X-HE-Tag: 1742202170-711468 X-HE-Meta: U2FsdGVkX1+oV907NgekKqO2tB4I6HCC8g4VAxAh6ZHfGyCGATjxEp21p56E4inJ4axq/ueD/i65L8rXCv7+NwHzUrSEPNk2adeBcVOdp9b9n2W+tIklKFTjNdAvIfqscafeGNY6KNvc+pe//tA7hEe7cbMdqdVb/zW/lSQI32jqmQymCYlemCc9UV5R2e6E6Hi9KMeN8fK3ZEXyacr+5ZsMX9fbx020MkZzNV+btWW63XI1xNo9Mig9PpaH+N8zyUPx9q1ueysxmXg1EvSrQLIzfcpb/6rhns/IXe+iTEFJfbPpSzBWTpmI6fc1X0E2DlXYQ5quQWk9ISFK54SAg9KqkxMUewDPh9Fsq8uTL/PJl5OpT2fSenF29oy9nT9ehV2zIgjsjTOAc3U8fWBd3OXS30S0sn2RifzIo+fW8hOD0ogzvNi0/wGdTXGhftcOrLIHMH1y3xYyQ6/0DxZ29i0tt7snz/UzQDD6SQjayhe8KFAGpRztIsLGvEKu9WvHVcBMRES2ZL0RVaKat/5n6CJ1XZREKII9t9nH4TlercGjCh05pvK4mtF/o6R9edWGOuTn0Ef1m3I1m/UcnRZTqeUgints6yUQ9XndtCxH9Ysvb232TAo5yBKbauWuuElLqgPYhDFSA4Cfqf/VOmbK7vQt7+8iZ6dPRi2aCnKg5Z5STTk/F183kJ4GlsvAJMu0/rw/rwNmGfOaqOEqhFaUlhNTZtMJyiRrarQbSI/3SONCsHFYRuWiOc0Rt6KeM4OVQl0UOJVf9Wdo4zRuzK6H9XYL5fha5I1IgaD1uiQnrdg3He76OabNbg6BepcRhryjUkElnb1GF5KeOTim6kgpyoZ9HAq5RRhD31a0LB7EincElvzW+n+pFmSzkafEy+mfitOiNiqddUzVBo0BvRnJXckmTx5EDMipP5R9SCAgldkPlEaZ7hEZnpe3u8rMAPfaU1xpXwMPTSto7T2+JU8 wwkkpvEp JaVZJ36CqEJnaJU2KXCCuTj9J2pB5kSm908PQzmS+E47SK4mNLbggFwOpXdP2l1s6mSFWQPzpn0yke4BKaBwI4Ca5L8SScVSqzYC702nz7Ox/ylemEg6cAEb6X8mg8lfLYKK//vO9DrMrcfg2/xoZN0tyGBZnSmvE5iLli/x2ZRJpYFA4BlXZ0alwIKFZiVxmDk39fV97t+vX5gJQHWf7S1nUVSnZxMUWp0hNg8SCnimzcQJ/9CuUH2aDgyuy6rogydJMriXV6ktCTBWREvFtim323IZMFrXB5PM/8DY0HfpaWXCUgtnYjYysOMgHEUg2JMvO7bZ1N72jCo0tNah9EQg8oT7eC0OpvjP0zqzQ3cP/iRVklMrS2BJgc8W9KiDGTZ81foLswiqZUApvueuHfIg2oQ== 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 3/17/25 06:42, Harry Yoo wrote: > On Fri, Mar 14, 2025 at 01:32:16PM +0100, Mateusz Guzik wrote: >> >> 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 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. >> > >> > 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 imply some locking between the shrinker and slab allocator so it doesn't hand out 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 free mm_struct objects in partially full slabs due to fragmentation, but I doubt we'd need to worry specifically about the percpu memory those "own".