From: Sergey Senozhatsky <senozhatsky@chromium.org>
To: Yosry Ahmed <yosry.ahmed@linux.dev>
Cc: Sergey Senozhatsky <senozhatsky@chromium.org>,
Andrew Morton <akpm@linux-foundation.org>,
Minchan Kim <minchan@kernel.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Kairui Song <ryncsn@gmail.com>
Subject: Re: [PATCHv4 14/17] zsmalloc: make zspage lock preemptible
Date: Fri, 14 Feb 2025 12:33:33 +0900 [thread overview]
Message-ID: <sio5jxzi5fsdcfpgbifna6d6ipwvbrxftogeyxpqim74yeptd4@gaqzwxsrkoud> (raw)
In-Reply-To: <Z64O3w2p1NrXoicl@google.com>
On (25/02/13 15:25), Yosry Ahmed wrote:
> On Thu, Feb 13, 2025 at 05:22:20PM +0900, Sergey Senozhatsky wrote:
> > On (25/02/13 16:21), Sergey Senozhatsky wrote:
> > > BASE
> > > ====
> > >
> > > 1363.64user 157.08system 1:30.89elapsed 1673%CPU (0avgtext+0avgdata 825692maxresident)k
> > >
> > > lock stats
> > >
> > > class name con-bounces contentions waittime-min waittime-max waittime-total waittime-avg acq-bounces acquisitions holdtime-min holdtime-max holdtime-total holdtime-avg
> > > &pool->migrate_lock-R: 0 0 0.00 0.00 0.00 0.00 10001 702081 0.14 104.74 125571.64 0.18
> > > &class->lock: 1 1 0.25 0.25 0.25 0.25 6320 840542 0.06 809.72 191214.87 0.23
> > > &zspage->lock-R: 0 0 0.00 0.00 0.00 0.00 6452 664129 0.12 660.24 201888.61 0.30
> > > &zram->table[index].lock: 0 0 0.00 0.00 0.00 0.00 1716362 3096466 0.07 811.10 365551.24 0.12
> > > &zstrm->lock: 0 0 0.00 0.00 0.00 0.00 0 664129 1.68 1004.80 14853571.32 22.37
> > >
> > > PATCHED
> > > =======
> > >
> > > 1366.50user 154.89system 1:30.33elapsed 1684%CPU (0avgtext+0avgdata 825692maxresident)k
> > >
> > > lock stats
> > >
> > > class name con-bounces contentions waittime-min waittime-max waittime-total waittime-avg acq-bounces acquisitions holdtime-min holdtime-max holdtime-total holdtime-avg
> > > &pool->lock#3-R: 0 0 0.00 0.00 0.00 0.00 3648 701979 0.12 44.09 107333.02 0.15
> > > &class->lock: 0 0 0.00 0.00 0.00 0.00 5038 840434 0.06 1245.90 211814.60 0.25
> > > zsmalloc-page-R: 0 0 0.00 0.00 0.00 0.00 0 664078 0.05 699.35 236641.75 0.36
> > > zram-entry->lock: 0 0 0.00 0.00 0.00 0.00 0 3098328 0.06 2987.02 313339.11 0.10
> > > &per_cpu_ptr(comp->stream, cpu)->lock: 0 0 0.00 0.00 0.00 0.00 23 664078 1.77 7071.30 14838397.61 22.34
> >
> > So...
> >
> > I added lock-stat handling to zspage->lock and to zram (in zram it's only
> > trylock that we can track, but it doesn't really bother me). I also
> > renamed zsmalloc-page-R to old zspage->lock-R and zram-entry->lock to
> > old zram->table[index].lock, just in case if anyone cares.
> >
> > Now bounces stats for zspage->lock and zram->table[index].lock look
> > pretty much like in BASE case.
> >
> > PATCHED
> > =======
> >
> > class name con-bounces contentions waittime-min waittime-max waittime-total waittime-avg acq-bounces acquisitions holdtime-min holdtime-max holdtime-total holdtime-avg
> > &pool->lock#3-R: 0 0 0.00 0.00 0.00 0.00 2702 703841 0.22 873.90 197110.49 0.28
> > &class->lock: 0 0 0.00 0.00 0.00 0.00 4590 842336 0.10 3329.63 256595.70 0.30
> > zspage->lock-R: 0 0 0.00 0.00 0.00 0.00 4750 665011 0.08 3360.60 258402.21 0.39
> > zram->table[index].lock: 0 0 0.00 0.00 0.00 0.00 1722291 3099346 0.12 6943.09 721282.34 0.23
> > &per_cpu_ptr(comp->stream, cpu)->lock: 0 0 0.00 0.00 0.00 0.00 23 665011 2.84 7062.18 14896206.16 22.40
> >
>
> holdtime-max and holdtime-total are higher in the patched kernel. Not
> sure if this is just an artifact of lock holders being preemtible.
Hmm, pool->lock shouldn't be affected at all, however BASE holds it much
longer than PATCHED
holdtime-max holdtime-total
BASE 104.74 125571.64
PATCHED 44.09 107333.02
Doesn't make sense. I can understand zspage->lock and
zram->table[index].lock, but for zram->table[index] things look
strange (comparing run #1 and #2)
holdtime-total
BASE 365551.24
PATCHED 313339.11
And run #3 is in its own league.
Very likely just a very very bad way to test things.
Re-based on 6.14.0-rc2-next-20250213.
BASE
====
PREEMPT_NONE
class name con-bounces contentions waittime-min waittime-max waittime-total waittime-avg acq-bounces acquisitions holdtime-min holdtime-max holdtime-total holdtime-avg
&pool->migrate_lock-R: 0 0 0.00 0.00 0.00 0.00 3624 702276 0.15 35.96 126562.90 0.18
&class->lock: 0 0 0.00 0.00 0.00 0.00 5084 840733 0.06 795.26 183238.22 0.22
&zspage->lock-R: 0 0 0.00 0.00 0.00 0.00 5358 664228 0.12 43.71 192732.71 0.29
&zram->table[index].lock: 0 0 0.00 0.00 0.00 0.00 1528645 3095862 0.07 764.76 370881.23 0.12
&zstrm->lock: 0 0 0.00 0.00 0.00 0.00 0 664228 2.52 2033.81 14605911.45 21.99
PREEMPT_VOLUNTARY
class name con-bounces contentions waittime-min waittime-max waittime-total waittime-avg acq-bounces acquisitions holdtime-min holdtime-max holdtime-total holdtime-avg
&pool->migrate_lock-R: 0 0 0.00 0.00 0.00 0.00 3039 699556 0.14 50.78 125553.59 0.18
&class->lock: 0 0 0.00 0.00 0.00 0.00 5259 838005 0.06 943.43 177108.05 0.21
&zspage->lock-R: 0 0 0.00 0.00 0.00 0.00 5581 664096 0.12 81.56 190235.48 0.29
&zram->table[index].lock: 0 0 0.00 0.00 0.00 0.00 1731706 3098570 0.07 796.87 366934.54 0.12
&zstrm->lock: 0 0 0.00 0.00 0.00 0.00 0 664096 3.38 5074.72 14472697.91 21.79
PREEMPT
class name con-bounces contentions waittime-min waittime-max waittime-total waittime-avg acq-bounces acquisitions holdtime-min holdtime-max holdtime-total holdtime-avg
&pool->migrate_lock-R: 0 0 0.00 0.00 0.00 0.00 2545 701827 0.14 773.56 125463.37 0.18
&class->lock: 0 0 0.00 0.00 0.00 0.00 4697 840281 0.06 1701.18 231657.38 0.28
&zspage->lock-R: 0 0 0.00 0.00 0.00 0.00 4778 664002 0.12 755.62 181215.17 0.27
&zram->table[index].lock: 0 0 0.00 0.00 0.00 0.00 1731737 3096937 0.07 1703.92 384633.29 0.12
&zstrm->lock: 0 0 0.00 0.00 0.00 0.00 0 664002 2.85 3603.20 14586900.58 21.97
So somehow holdtime-max for per-CPU stream is 2.5x higher for PREEMPT_VOLUNTARY
than for PREEMPT_NONE. And class->lock holdtime-total is much much higher for
PREEMPT than for any other preemption models. And that's BASE kernel, which
runs fully atomic zsmalloc and zram. I call this rubbish.
next prev parent reply other threads:[~2025-02-14 3:33 UTC|newest]
Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-31 9:05 [PATCHv4 00/17] zsmalloc/zram: there be preemption Sergey Senozhatsky
2025-01-31 9:06 ` [PATCHv4 01/17] zram: switch to non-atomic entry locking Sergey Senozhatsky
2025-01-31 11:41 ` Hillf Danton
2025-02-03 3:21 ` Sergey Senozhatsky
2025-02-03 3:52 ` Sergey Senozhatsky
2025-02-03 12:39 ` Sergey Senozhatsky
2025-01-31 22:55 ` Andrew Morton
2025-02-03 3:26 ` Sergey Senozhatsky
2025-02-03 7:11 ` Sergey Senozhatsky
2025-02-03 7:33 ` Sergey Senozhatsky
2025-02-04 0:19 ` Andrew Morton
2025-02-04 4:22 ` Sergey Senozhatsky
2025-02-06 7:01 ` Sergey Senozhatsky
2025-02-06 7:38 ` Sebastian Andrzej Siewior
2025-02-06 7:47 ` Sergey Senozhatsky
2025-02-06 8:13 ` Sebastian Andrzej Siewior
2025-02-06 8:17 ` Sergey Senozhatsky
2025-02-06 8:26 ` Sebastian Andrzej Siewior
2025-02-06 8:29 ` Sergey Senozhatsky
2025-01-31 9:06 ` [PATCHv4 02/17] zram: do not use per-CPU compression streams Sergey Senozhatsky
2025-02-01 9:21 ` Kairui Song
2025-02-03 3:49 ` Sergey Senozhatsky
2025-02-03 21:00 ` Yosry Ahmed
2025-02-06 12:26 ` Sergey Senozhatsky
2025-02-06 6:55 ` Kairui Song
2025-02-06 7:22 ` Sergey Senozhatsky
2025-02-06 8:22 ` Sergey Senozhatsky
2025-02-06 16:16 ` Yosry Ahmed
2025-02-07 2:56 ` Sergey Senozhatsky
2025-02-07 6:12 ` Sergey Senozhatsky
2025-02-07 21:07 ` Yosry Ahmed
2025-02-08 16:20 ` Sergey Senozhatsky
2025-02-08 16:41 ` Sergey Senozhatsky
2025-02-09 6:22 ` Sergey Senozhatsky
2025-02-09 7:42 ` Sergey Senozhatsky
2025-01-31 9:06 ` [PATCHv4 03/17] zram: remove crypto include Sergey Senozhatsky
2025-01-31 9:06 ` [PATCHv4 04/17] zram: remove max_comp_streams device attr Sergey Senozhatsky
2025-01-31 9:06 ` [PATCHv4 05/17] zram: remove two-staged handle allocation Sergey Senozhatsky
2025-01-31 9:06 ` [PATCHv4 06/17] zram: permit reclaim in zstd custom allocator Sergey Senozhatsky
2025-01-31 9:06 ` [PATCHv4 07/17] zram: permit reclaim in recompression handle allocation Sergey Senozhatsky
2025-01-31 9:06 ` [PATCHv4 08/17] zram: remove writestall zram_stats member Sergey Senozhatsky
2025-01-31 9:06 ` [PATCHv4 09/17] zram: limit max recompress prio to num_active_comps Sergey Senozhatsky
2025-01-31 9:06 ` [PATCHv4 10/17] zram: filter out recomp targets based on priority Sergey Senozhatsky
2025-01-31 9:06 ` [PATCHv4 11/17] zram: unlock slot during recompression Sergey Senozhatsky
2025-01-31 9:06 ` [PATCHv4 12/17] zsmalloc: factor out pool locking helpers Sergey Senozhatsky
2025-01-31 15:46 ` Yosry Ahmed
2025-02-03 4:57 ` Sergey Senozhatsky
2025-01-31 9:06 ` [PATCHv4 13/17] zsmalloc: factor out size-class " Sergey Senozhatsky
2025-01-31 9:06 ` [PATCHv4 14/17] zsmalloc: make zspage lock preemptible Sergey Senozhatsky
2025-01-31 15:51 ` Yosry Ahmed
2025-02-03 3:13 ` Sergey Senozhatsky
2025-02-03 4:56 ` Sergey Senozhatsky
2025-02-03 21:11 ` Yosry Ahmed
2025-02-04 6:59 ` Sergey Senozhatsky
2025-02-04 17:19 ` Yosry Ahmed
2025-02-05 2:43 ` Sergey Senozhatsky
2025-02-05 19:06 ` Yosry Ahmed
2025-02-06 3:05 ` Sergey Senozhatsky
2025-02-06 3:28 ` Sergey Senozhatsky
2025-02-06 16:19 ` Yosry Ahmed
2025-02-07 2:48 ` Sergey Senozhatsky
2025-02-07 21:09 ` Yosry Ahmed
2025-02-12 5:00 ` Sergey Senozhatsky
2025-02-12 15:35 ` Yosry Ahmed
2025-02-13 2:18 ` Sergey Senozhatsky
2025-02-13 2:57 ` Yosry Ahmed
2025-02-13 7:21 ` Sergey Senozhatsky
2025-02-13 8:22 ` Sergey Senozhatsky
2025-02-13 15:25 ` Yosry Ahmed
2025-02-14 3:33 ` Sergey Senozhatsky [this message]
2025-01-31 9:06 ` [PATCHv4 15/17] zsmalloc: introduce new object mapping API Sergey Senozhatsky
2025-01-31 9:06 ` [PATCHv4 16/17] zram: switch to new zsmalloc " Sergey Senozhatsky
2025-01-31 9:06 ` [PATCHv4 17/17] zram: add might_sleep to zcomp API Sergey Senozhatsky
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=sio5jxzi5fsdcfpgbifna6d6ipwvbrxftogeyxpqim74yeptd4@gaqzwxsrkoud \
--to=senozhatsky@chromium.org \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=minchan@kernel.org \
--cc=ryncsn@gmail.com \
--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