From: Sergey Senozhatsky <senozhatsky@chromium.org>
To: Vitaly Wool <vitaly.wool@konsulko.se>
Cc: Yosry Ahmed <yosry.ahmed@linux.dev>,
linux-mm@kvack.org, akpm@linux-foundation.org,
linux-kernel@vger.kernel.org, Nhat Pham <nphamcs@gmail.com>,
Shakeel Butt <shakeel.butt@linux.dev>,
Johannes Weiner <hannes@cmpxchg.org>,
Igor Belousov <igor.b@beldev.am>,
Minchan Kim <minchan@kernel.org>,
Sergey Senozhatsky <senozhatsky@chromium.org>
Subject: Re: [PATCH v4] mm: add zblock allocator
Date: Fri, 2 May 2025 08:43:22 +0900 [thread overview]
Message-ID: <uducoj43wg46d756fxbgdwsnql4kff5if6psuly75qfimk44yg@vbu3cf2ealjn> (raw)
In-Reply-To: <c612aff8-1b07-43aa-b909-f555da511da2@konsulko.se>
On (25/05/01 14:41), Vitaly Wool wrote:
[..]
> Bottom line, ending up with a lot of blocks each containing a single object
> is not a real life scenario.
Why not? What if the data patterns do not favor compressible objects?
E.g. what if the distribution of compressed objects looks like this (a real
zsmalloc stats):
size-class objs-allocated
---------------------------
...
1904 3315
1920 3468
1936 3515
2048 25816
2144 22363
2160 3230
2176 3075
2192 2990
2224 5665
2272 8118
2304 5040
2336 4529
2384 6132
2400 1768
2448 4825
2512 5135
2560 2944
2592 1562
2624 1512
2720 3813
2832 3315
2864 820
...
Notice tenth of thousands of 2048-2144 bytes objects. zsmalloc size
classes are fundamentally independent of each other and, hence, of
the compressed objects distribution: the lack of objects, or even
"the absence of" for that matter, in size-class 256 does not change
a thing for size-class 2048. This is a very important property.
next prev parent reply other threads:[~2025-05-01 23:43 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-12 15:42 Vitaly Wool
2025-04-12 19:25 ` Igor Belousov
2025-04-16 12:09 ` Johannes Weiner
2025-04-16 20:10 ` Vitaly
2025-04-17 14:16 ` Johannes Weiner
2025-04-18 7:43 ` Vitaly Wool
2025-04-18 10:52 ` David Hildenbrand
2025-04-18 10:56 ` Vitaly Wool
2025-04-18 11:03 ` David Hildenbrand
2025-04-22 10:46 ` Yosry Ahmed
2025-04-23 19:53 ` Vitaly Wool
2025-04-30 12:27 ` Yosry Ahmed
2025-05-01 12:41 ` Vitaly Wool
2025-05-01 23:43 ` Sergey Senozhatsky [this message]
2025-05-06 13:04 ` Yosry Ahmed
2025-06-11 17:11 ` Vitaly Wool
2025-05-01 23:49 ` Sergey Senozhatsky
2025-05-03 8:27 ` Vitaly
2025-05-04 9:26 ` Andrew Morton
2025-07-20 2:56 ` Andrew Morton
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=uducoj43wg46d756fxbgdwsnql4kff5if6psuly75qfimk44yg@vbu3cf2ealjn \
--to=senozhatsky@chromium.org \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=igor.b@beldev.am \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=minchan@kernel.org \
--cc=nphamcs@gmail.com \
--cc=shakeel.butt@linux.dev \
--cc=vitaly.wool@konsulko.se \
--cc=yosry.ahmed@linux.dev \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox