Received-SPF: pass (google.com: domain of linux-kernel+bounces-193854-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Precedence: bulk
MIME-Version: 1.0
References: <f184a2d6-7892-4e43-a0cd-cab638c3d5c2@amd.com> <096178c9-91de-4752-bdc4-6a31bcdcbaf8@amd.com>
 <4871a305-5d45-47d2-85f2-d718c423db80@canonical.com> <CAGudoHFkDmGuPQDLf6rfiJxUdqFxjeeM-_9rFCApSrBYzfyRmA@mail.gmail.com>
 <3b880c7c-0d19-4bb6-9f0f-fb69047f41cd@canonical.com> <CAGudoHEycK3iTO2Rrsqr56_Lm69rCzMRaYz11NLrOcn5gKB3RA@mail.gmail.com>
 <5c94947b-1f1f-44a7-8b9c-b701c78350b4@canonical.com> <CAGudoHFxma+H_iHPV8+gfEkHc0uwFD8=rJtFy7ZE3TH+7tGiwQ@mail.gmail.com>
 <78cfe966-33ec-4858-b114-57697e478109@canonical.com>
In-Reply-To: <78cfe966-33ec-4858-b114-57697e478109@canonical.com>
From: Mateusz Guzik <mjguzik@gmail.com>
Date: Wed, 29 May 2024 11:38:04 +0200
Message-ID: <CAGudoHGqvAuAYnc75xRhSMYfxRbgpQuCYnxUWiCXJM8YtGJxjQ@mail.gmail.com>
Subject: Re: [RFC 0/9] Nginx refcount scalability issue with Apparmor enabled
 and potential solutions
To: John Johansen <john.johansen@canonical.com>
Cc: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>, paul@paul-moore.com, jmorris@namei.org, 
	serge@hallyn.com, linux-security-module@vger.kernel.org, 
	linux-kernel@vger.kernel.org, "Gautham R. Shenoy" <gautham.shenoy@amd.com>, 
	"Shukla, Santosh" <Santosh.Shukla@amd.com>, "Narayan, Ananth" <Ananth.Narayan@amd.com>, 
	raghavendra.kodsarathimmappa@amd.com, koverstreet@google.com, 
	paulmck@kernel.org, boqun.feng@gmail.com, vinicius.gomes@intel.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, May 29, 2024 at 2:37=E2=80=AFAM John Johansen
<john.johansen@canonical.com> wrote:
> I don't have objections to moving towards percpu refcounts, but the overh=
ead
> of a percpu stuct per label is a problem when we have thousands of labels
> on the system. That is to say, this would have to be a config option. We
> moved buffers from kmalloc to percpu to reduce memory overhead to reduce
> contention. The to percpu, to a global pool because the percpu overhead w=
as
> too high for some machines, and then from a global pool to a hybrid schem=
e
> because of global lock contention. I don't see a way of doing that with t=
he
> label, which means a config would be the next best thing.
>

There was a patchset somewhere which adds counters starting as atomic
and automagically converting themselves per-cpu if there as enough
load applied to them. General point being it is plausible this may
autotune itself.

Another option would be a boot-time tunable.

> Not part of your patch but something to be considered is that the label t=
ree
> needs a rework, its locking needs to move to read side a read side lock l=
ess
> scheme, and the plan was to make it also use a linked list such that new
> labels are always queued at the end, allowing dynamically created labels =
to
> be lazily added to the tree.
>

It's not *my* patchset. ;)

> I see the use of the kworker as problematic as well, especially if we are
> talking using kconfig to switch reference counting modes. I am futzing wi=
th
> some ideas, on how to deal with this.
>

Thanks for the update. Hopefully this is going to get sorted out in
the foreseeable future.

--=20
Mateusz Guzik <mjguzik gmail.com>