[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190509165343.GX374014@devbig004.ftw2.facebook.com>
Date: Thu, 9 May 2019 09:53:43 -0700
From: Tejun Heo <tj@...nel.org>
To: Roman Gushchin <guro@...com>
Cc: Jens Axboe <axboe@...nel.dk>, Song Liu <songliubraving@...com>,
Dennis Zhou <dennis@...nel.org>, linux-kernel@...r.kernel.org,
kernel-team@...com
Subject: Re: [PATCH 1/4] percpu_ref: introduce PERCPU_REF_ALLOW_REINIT flag
On Tue, May 07, 2019 at 10:01:47AM -0700, Roman Gushchin wrote:
> In most cases percpu reference counters are not switched to the
> percpu mode after they reach the atomic mode. Some obvious exceptions
> are reference counters which are initialized into the atomic
> mode (using PERCPU_REF_INIT_ATOMIC and PERCPU_REF_INIT_DEAD flags),
> and there are few other exceptions.
>
> But in most cases there is no way back, and once the reference counter
> is switched to the atomic mode, there is no reason to wait for
> percpu_ref_exit() to release the percpu memory. Of course, the size
> of a single counter is not so big, but because it can pin the whole
> percpu block in memory, the memory footprint can be noticeable
> (e.g. on my 32 CPUs machine a percpu block is 8Mb large).
>
> To make releasing of the percpu memory as early as possible, let's
> introduce the PERCPU_REF_ALLOW_REINIT flag with the following semantics:
> it has to be set in order to switch a percpu reference counter to the
> percpu mode after the initialization. PERCPU_REF_INIT_ATOMIC and
> PERCPU_REF_INIT_DEAD flags will implicitly assume PERCPU_REF_ALLOW_REINIT.
>
> This patch doesn't introduce any functional change to avoid any
> regressions. It will be done later in the patchset after adjusting
> all call sites, which are reviving percpu counters.
>
> Signed-off-by: Roman Gushchin <guro@...com>
For all patches in the series:
Acked-by: Tejun Heo <tj@...rel.org>
Thanks.
--
tejun
Powered by blists - more mailing lists