Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 17 Apr 2023 21:37:40 +0900
From:   Sergey Senozhatsky <senozhatsky@chromium.org>
To:     Yosry Ahmed <yosryahmed@google.com>
Cc:     Sergey Senozhatsky <senozhatsky@chromium.org>,
        Minchan Kim <minchan@kernel.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH] zsmalloc: allow only one active pool compaction context
Message-ID: <20230417123740.GP25053@google.com>
References: <20230417110259.1737315-1-senozhatsky@chromium.org>
 <CAJD7tkbVnwV0t8BPqVcY7+gooW8NSs=nq2U0TuQC5ZP1xhVSNg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAJD7tkbVnwV0t8BPqVcY7+gooW8NSs=nq2U0TuQC5ZP1xhVSNg@mail.gmail.com>
Precedence: bulk

Hi,

On (23/04/17 04:53), Yosry Ahmed wrote:
> > Introduce pool compaction mutex and permit only one compaction
> > context at a time.
> 
> I am not sure what's the best practice here, but if the only use of
> the mutex is a trylock, do we need a mutex here? It seems like a
> simple atomic would do the trick. Perhaps something like:
> 
> static atomic_t ongoing_compaction = ATOMIC_INIT(0);
> ...
> if (atomic_xchg(&ongoing_compaction, 1))
>     return;
> ....
> atomic_set(&ongoing_compaction, 0);

Looks good to me. Will switch to atomic_t in v2.