From: "Yosry Ahmed" <yosry.ahmed@linux.dev>
To: "Sergey Senozhatsky" <senozhatsky@chromium.org>
Cc: "Sergey Senozhatsky" <senozhatsky@chromium.org>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Kairui Song" <ryncsn@gmail.com>,
"Minchan Kim" <minchan@kernel.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 10/18] zsmalloc: factor out pool locking helpers
Date: Thu, 13 Feb 2025 01:12:51 +0000 [thread overview]
Message-ID: <28ed23c00effdd531a9e027feb0bc08e22fc677d@linux.dev> (raw)
In-Reply-To: <5htndqx74yv2lq2zr2odozrrbi5cz6zizn3vk4uosobn4ceoji@5zuknjmi26f6>
February 12, 2025 at 4:57 PM, "Sergey Senozhatsky" <senozhatsky@chromium.org> wrote:
>
> On (25/02/12 16:18), Yosry Ahmed wrote:
>
> >
> > On Wed, Feb 12, 2025 at 03:27:08PM +0900, Sergey Senozhatsky wrote:
> >
> > We currently have a mix of migrate_{read,write}_lock() helpers
> >
> > that lock zspages, but it's zs_pool that actually has a ->migrate_lock
> >
> > access to which is opene-coded. Factor out pool migrate locking
> >
> > into helpers, zspage migration locking API will be renamed to
> >
> > reduce confusion.
> >
> >
> >
> > It's worth mentioning that zsmalloc locks sync not only migration,
> >
> > but also compaction.
> >
> >
> >
> > Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org>
> >
> >
> >
> > FWIW I don't see a lot of value in the helpers (renaming the lock is
> >
> > useful tho).
> >
>
> I want to hide the details, keep them in one place and at some
>
> point *in the future* have the same "locking rules" as for zspage
>
> lock. Also *possibly* throwing a couple of lockdep assertions.
>
> So I'd prefer to abstract all of these.
I'd prefer to introduce the abstractions when they are needed tbh. Right now they just make the code less readable.
next prev parent reply other threads:[~2025-02-13 1:12 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-12 6:26 [PATCH v5 00/18] zsmalloc/zram: there be preemption Sergey Senozhatsky
2025-02-12 6:26 ` [PATCH v5 01/18] zram: sleepable entry locking Sergey Senozhatsky
2025-02-13 0:08 ` Andrew Morton
2025-02-13 0:52 ` Sergey Senozhatsky
2025-02-13 1:42 ` Sergey Senozhatsky
2025-02-13 8:49 ` Sergey Senozhatsky
2025-02-12 6:27 ` [PATCH v5 02/18] zram: permit preemption with active compression stream Sergey Senozhatsky
2025-02-12 16:01 ` Yosry Ahmed
2025-02-13 1:04 ` Sergey Senozhatsky
2025-02-12 6:27 ` [PATCH v5 03/18] zram: remove crypto include Sergey Senozhatsky
2025-02-12 16:13 ` Yosry Ahmed
2025-02-13 0:53 ` Sergey Senozhatsky
2025-02-12 6:27 ` [PATCH v5 04/18] zram: remove max_comp_streams device attr Sergey Senozhatsky
2025-02-12 6:27 ` [PATCH v5 05/18] zram: remove two-staged handle allocation Sergey Senozhatsky
2025-02-12 6:27 ` [PATCH v5 06/18] zram: remove writestall zram_stats member Sergey Senozhatsky
2025-02-12 6:27 ` [PATCH v5 07/18] zram: limit max recompress prio to num_active_comps Sergey Senozhatsky
2025-02-12 6:27 ` [PATCH v5 08/18] zram: filter out recomp targets based on priority Sergey Senozhatsky
2025-02-12 6:27 ` [PATCH v5 09/18] zram: rework recompression loop Sergey Senozhatsky
2025-02-12 6:27 ` [PATCH v5 10/18] zsmalloc: factor out pool locking helpers Sergey Senozhatsky
2025-02-12 16:18 ` Yosry Ahmed
2025-02-12 16:19 ` Yosry Ahmed
2025-02-13 0:57 ` Sergey Senozhatsky
2025-02-13 1:12 ` Yosry Ahmed [this message]
2025-02-13 2:54 ` Sergey Senozhatsky
2025-02-12 6:27 ` [PATCH v5 11/18] zsmalloc: factor out size-class " Sergey Senozhatsky
2025-02-12 6:27 ` [PATCH v5 12/18] zsmalloc: make zspage lock preemptible Sergey Senozhatsky
2025-02-12 17:14 ` Yosry Ahmed
2025-02-13 1:20 ` Sergey Senozhatsky
2025-02-13 1:31 ` Yosry Ahmed
2025-02-13 1:53 ` Sergey Senozhatsky
2025-02-13 11:32 ` Hillf Danton
2025-02-13 12:29 ` Sergey Senozhatsky
2025-02-12 6:27 ` [PATCH v5 13/18] zsmalloc: introduce new object mapping API Sergey Senozhatsky
2025-02-12 6:27 ` [PATCH v5 14/18] zram: switch to new zsmalloc " Sergey Senozhatsky
2025-02-12 6:27 ` [PATCH v5 15/18] zram: permit reclaim in zstd custom allocator Sergey Senozhatsky
2025-02-12 6:27 ` [PATCH v5 16/18] zram: do not leak page on recompress_store error path Sergey Senozhatsky
2025-02-12 6:27 ` [PATCH v5 17/18] zram: do not leak page on writeback_store " Sergey Senozhatsky
2025-02-12 6:27 ` [PATCH v5 18/18] zram: add might_sleep to zcomp API Sergey Senozhatsky
2025-02-13 0:09 ` [PATCH v5 00/18] zsmalloc/zram: there be preemption Andrew Morton
2025-02-13 0:51 ` 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=28ed23c00effdd531a9e027feb0bc08e22fc677d@linux.dev \
--to=yosry.ahmed@linux.dev \
--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=senozhatsky@chromium.org \
/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