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 10B0BCE7AA0 for ; Thu, 5 Sep 2024 21:52:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 722BE6B0083; Thu, 5 Sep 2024 17:52:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6AA666B0085; Thu, 5 Sep 2024 17:52:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 54AFF6B0088; Thu, 5 Sep 2024 17:52:14 -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 336DF6B0083 for ; Thu, 5 Sep 2024 17:52:14 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 7BE291A0B88 for ; Thu, 5 Sep 2024 21:52:13 +0000 (UTC) X-FDA: 82532033346.23.807ECFC Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf09.hostedemail.com (Postfix) with ESMTP id D0C3814001A for ; Thu, 5 Sep 2024 21:52:11 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=XVMkW2S2; spf=pass (imf09.hostedemail.com: domain of akpm@linux-foundation.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1725573002; 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=PS2UhVspOJXC7PppGUKWEorXnT71CwIN0ra8eix4Psg=; b=wQHBwyUTNLtAZyIqKX5aOrIeqDaX1tKCkI8C3oKJPGAzYaXA7JwXNgtqaEcEihGMHpKbmt TgEBdnlKNGc/+q821TlAWjOyeDTsA7XY/MmDXnRAHAyBKAqAnJKQ5MAD26Ux7fH/L19dE4 44/hvJhM8BwcGa0R4K6h8eATsCiCs2g= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=XVMkW2S2; spf=pass (imf09.hostedemail.com: domain of akpm@linux-foundation.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725573002; a=rsa-sha256; cv=none; b=td8B8lVc4SeEjSuow5oX9Iyg0dH2havQ8eOBJTFpz9JVB7GiCXM9vr+W1RfGMbQl+Di+QC Dyac4CnDXTeDNBP5b+C2EJRS5SA734oRtlNX2tHEkMnNPvNaCLhlOd7NThKeiE8re739ga +BgDKSnX9UlpBmE+OOkuQQTUL684RZE= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 9E5D2A40D7D; Thu, 5 Sep 2024 21:52:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 67938C4CEC3; Thu, 5 Sep 2024 21:52:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1725573130; bh=nsVttku8Ehjht7aRVWo/nNmZgVfMucfOC9yPnXrjKYg=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=XVMkW2S2G2B2+XskqoX3BbRlSWeauWdPo9CZhkSGv+KMPW3WXbL/pF0LGsu0jHhYz 6osraO+B38LYPRsaDIS2zCXYoFCoqSMZ+hJxgqQu5yZbqbtrhRIuuGDgX2pOc+me2T iTc3iY6pL3MCZyloqZ0JK50F9BCAMQI/nArSGc9U= Date: Thu, 5 Sep 2024 14:52:09 -0700 From: Andrew Morton To: Sergey Senozhatsky Cc: Minchan Kim , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm: use unique zsmalloc caches names Message-Id: <20240905145209.641c8f127ba353832a1be778@linux-foundation.org> In-Reply-To: <20240905064736.2250735-1-senozhatsky@chromium.org> References: <20240905064736.2250735-1-senozhatsky@chromium.org> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: D0C3814001A X-Stat-Signature: 3b4bz9hx78tycsizkud9typtwihr6rpc X-Rspam-User: X-HE-Tag: 1725573131-935327 X-HE-Meta: U2FsdGVkX1+YdkN05gK8cbmh5J7u0Hc8bPLp1yx64zzdRVo65vKsuqoSziGV8yMh0Tt8a1JxN3Qc/IuzYnZD1kSsH7rFnC4Q+olIxU5GKV74om5/jGYPqLDTeyqxs1zb+OWCREa1n52Yam+xStvryx0ff5vIiTl4xtPYikfj/C141plaT2g+RcsMWCwSB8S21y77HAhD75Qw152mgvGN9eBQPuAEx0clj96S0ObyJtD4f8sKILi+A8THu6btM0kS1phYWXaTIUW/namQH4LczUpqUs0qg+HfBXbtZsootaOpQm24jHLwoWw1RotYbhaj7NIgqW3uP3b9I3XTOIh713f/pMcrnE/tTJBS2WesG1Z9kfDr9nauWjBUCGH/EdiIYfcmA1Ht/DTEaHBlrbFdrPOZEnSlc/KaLAzNb6zM6uPZLv+iK0Be6E2AFJ0axy1RYXB7ZvvYCqcyClqLVFDE4XqrROqtHVWSpNnEGzliN1aLuv2jBb/LjKbZ0w+J4uiSOfSg3yQzfzQoGxug2XfCyrQ+Rwf05DcBYp6sy1oUqZ77ZxwAzHdX6Yh3kzhgLujglliHwjE7HFvgO+HcZ+Q4gZrSDPEloVh/EPCOI4JX3ICC9NsZAOXAYY+x4iQXrgSD7I4KKS6miv6H9txWilQ2x89v8Pm28akAXEmKHpWcfe/8TzY0kuI0jBi8s96+SA95IGeZ9AnXeTVOzSgVog5b4ec51Zd0A+oW60AZ91G/Ju8oeks2ZvJZcLoVnke8KRqHB7hjBXU+fkB0HH+3FWGjhlUp0Il4+0RvAyZDLIe8glhVDfx3DdpnqJsZlNcZHnRM0K2hH1WdaY6aX5S6T6hNBDlYQFyKeEGzjzb7cIa7HbOqR3bYV8RGTcNzXRZOY/auLcnztPnSNtLI2nZCtiUIQ5RcBGfz0b7oVqXFpYeaXunRC5Tey0MhQ5CeBwt4f0pV4eouz2eJohYkmtGqNA/ f6niOI6F OjTyQIb5XNpd6gwO+VQhb172hFrNnlDdODB8w6ixLxegzH79NC9hz5C0d+l+2GUEbFUMZJSE+aS3GLurVMaov0mp/8ZkNI8THJ8V5/fTwA/C981dbJAZxTlHyGIRi4KXJ9cIXscS1KfMimJOLYEw2lsg2ivulqCdcD645cZZ8dmWxj31+5SN5et6dqDYgqJSa2kIvgQHZT62VAwW0XyjSzkMC/5dnUqxZ2yrvuiD3rZpnRoaOp1bDMpSLYFIX8DrHvPZ2t2RaEYEt1yjZ3KeozhiP1A== 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 Thu, 5 Sep 2024 15:47:23 +0900 Sergey Senozhatsky wrote: > Each zsmalloc pool maintains several named kmem-caches for > zs_handle-s and zspage-s. On a system with multiple zsmalloc > pools and CONFIG_DEBUG_VM this triggers kmem_cache_sanity_check(): > > kmem_cache of name 'zspage' already exists > WARNING: at mm/slab_common.c:108 do_kmem_cache_create_usercopy+0xb5/0x310 > ... > > kmem_cache of name 'zs_handle' already exists > WARNING: at mm/slab_common.c:108 do_kmem_cache_create_usercopy+0xb5/0x310 > ... This is old code. Did something recently change to trigger this warning? > We provide zram device name when init its zsmalloc pool, so we can > use that same name for zsmalloc caches and, hence, create unique > names that can easily be linked to zram device that has created > them. > > So instead of having this > > cat /proc/slabinfo > slabinfo - version: 2.1 > zspage 46 46 ... > zs_handle 128 128 ... > zspage 34270 34270 ... > zs_handle 34816 34816 ... > zspage 0 0 ... > zs_handle 0 0 ... > > We now have this > > cat /proc/slabinfo > slabinfo - version: 2.1 > zspage-zram2 46 46 ... > zs_handle-zram2 128 128 ... > zspage-zram0 34270 34270 ... > zs_handle-zram0 34816 34816 ... > zspage-zram1 0 0 ... > zs_handle-zram1 0 0 ... > > --- a/mm/zsmalloc.c > +++ b/mm/zsmalloc.c > @@ -293,13 +293,17 @@ static void SetZsPageMovable(struct zs_pool *pool, struct zspage *zspage) {} > > static int create_cache(struct zs_pool *pool) > { > - pool->handle_cachep = kmem_cache_create("zs_handle", ZS_HANDLE_SIZE, > - 0, 0, NULL); > + char name[32]; > + > + snprintf(name, sizeof(name), "zs_handle-%s", pool->name); Always scary seeing code making such assumptions about it arguments in this fashion. Can we use kasprintf() and sleep well at night? > + pool->handle_cachep = kmem_cache_create(name, ZS_HANDLE_SIZE, > + 0, 0, NULL); > if (!pool->handle_cachep) > return 1; > > - pool->zspage_cachep = kmem_cache_create("zspage", sizeof(struct zspage), > - 0, 0, NULL); > + snprintf(name, sizeof(name), "zspage-%s", pool->name); > + pool->zspage_cachep = kmem_cache_create(name, sizeof(struct zspage), > + 0, 0, NULL); > if (!pool->zspage_cachep) { > kmem_cache_destroy(pool->handle_cachep); > pool->handle_cachep = NULL; I guess we want to backport this into earlier kernels? If so, what would be a suitable Fixes:?