From: Sergey Senozhatsky <senozhatsky@chromium.org>
To: Yosry Ahmed <yosryahmed@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Minchan Kim <minchan@kernel.org>,
Sergey Senozhatsky <senozhatsky@chromium.org>,
Vlastimil Babka <vbabka@suse.cz>,
David Rientjes <rientjes@google.com>,
Christoph Lameter <cl@linux.com>,
Erhard Furtner <erhard_f@mailbox.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm: zsmalloc: share slab caches for all zsmalloc zpools
Date: Wed, 5 Jun 2024 11:17:01 +0900 [thread overview]
Message-ID: <20240605021701.GB11718@google.com> (raw)
In-Reply-To: <20240604175340.218175-1-yosryahmed@google.com>
On (24/06/04 17:53), Yosry Ahmed wrote:
> Zswap creates multiple zpools to improve concurrency. Each zsmalloc
> zpool creates its own 'zs_handle' and 'zspage' slab caches. Currently we
> end up with 32 slab caches of each type.
>
> Since each slab cache holds some free objects, we end up with a lot of
> free objects distributed among the separate zpool caches. Slab caches
> are designed to handle concurrent allocations by using percpu
> structures, so having a single instance of each cache should be enough,
> and avoids wasting more memory than needed due to fragmentation.
>
> Additionally, having more slab caches than needed unnecessarily slows
> down code paths that iterate slab_caches.
>
> In the results reported by Eric in [1], the amount of unused slab memory
> in these caches goes down from 242808 bytes to 29216 bytes (-88%). This
> is calculated by (num_objs - active_objs) * objsize for each 'zs_handle'
> and 'zspage' cache. Although this patch did not help with the allocation
> failure reported by Eric with zswap + zsmalloc, I think it is still
> worth merging on its own.
>
> [1]https://lore.kernel.org/lkml/20240604134458.3ae4396a@yea/
>
> Signed-off-by: Yosry Ahmed <yosryahmed@google.com>
Makes perfect sense, thanks.
Reviewed-by: Sergey Senozhatsky <senozhatsky@chromium.org>
next prev parent reply other threads:[~2024-06-05 2:17 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-04 17:53 [PATCH] mm: zsmalloc: share slab caches for all zsmalloc zpools Yosry Ahmed
2024-06-04 20:54 ` Vlastimil Babka
2024-06-05 2:17 ` Sergey Senozhatsky [this message]
2024-06-06 22:36 ` Minchan Kim
2024-06-06 23:03 ` Yosry Ahmed
2024-06-06 23:10 ` Yosry Ahmed
2024-06-07 16:14 ` Minchan Kim
2024-06-07 17:24 ` Yosry Ahmed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240605021701.GB11718@google.com \
--to=senozhatsky@chromium.org \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=erhard_f@mailbox.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=minchan@kernel.org \
--cc=rientjes@google.com \
--cc=vbabka@suse.cz \
--cc=yosryahmed@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.