[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250221-095831-265429292-neomutt-senozhatsky@chromium.org>
Date: Sat, 22 Feb 2025 06:01:20 +0900
From: Sergey Senozhatsky <senozhatsky@...omium.org>
To: Yosry Ahmed <yosry.ahmed@...ux.dev>
Cc: Sergey Senozhatsky <senozhatsky@...omium.org>,
Andrew Morton <akpm@...ux-foundation.org>, Hillf Danton <hdanton@...a.com>, Kairui Song <ryncsn@...il.com>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>, Minchan Kim <minchan@...nel.org>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v7 11/17] zsmalloc: make zspage lock preemptible
On (25/02/21 19:48), Yosry Ahmed wrote:
[..]
> > +#ifdef CONFIG_DEBUG_LOCK_ALLOC
> > +#define zsl_dep_map(zsl) (&(zsl)->dep_map)
> > +#else
> > +#define zsl_dep_map(zsl) NULL
> > +#endif
> > +
> > +static void zspage_lock_init(struct zspage *zspage)
> > +{
> > +#ifdef CONFIG_DEBUG_LOCK_ALLOC
> > + lockdep_init_map(&zspage->zsl.dep_map, "zspage->lock",
> > + &zspage->pool->lock_class, 0);
>
> Can't we remove this #ifdef as well by adding a similar macro? (e.g.
> zsl_lock_class())
I thought about it but then was not sure if having a macro
that we use in two place is worth it, but I guess we can.
Let me send a v8.
Powered by blists - more mailing lists