[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87v7ruycfz.ffs@tglx>
Date: Thu, 27 Mar 2025 11:50:40 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: Eric Dumazet <edumazet@...gle.com>
Cc: Mateusz Guzik <mjguzik@...il.com>, kernel test robot
<oliver.sang@...el.com>, oe-lkp@...ts.linux.dev, lkp@...el.com,
linux-kernel@...r.kernel.org, x86@...nel.org, Benjamin Segall
<bsegall@...gle.com>, Frederic Weisbecker <frederic@...nel.org>
Subject: Re: [tip:timers/core] [posix] 1535cb8028:
stress-ng.epoll.ops_per_sec 36.2% regression
On Thu, Mar 27 2025 at 10:11, Eric Dumazet wrote:
> On Thu, Mar 27, 2025 at 9:26 AM Eric Dumazet <edumazet@...gle.com> wrote:
>
>> We could place all these atomic fields in separate cache lines,
>> to keep read-only fields shared as much as possible.
>>
>
> Following one-liner seems good enough to separate the 4 atomics used
> to control/limit
>
> UCOUNT_RLIMIT_NPROC, UCOUNT_RLIMIT_MSGQUEUE, UCOUNT_RLIMIT_SIGPENDING,
> UCOUNT_RLIMIT_MEMLOCK,
>
>
> diff --git a/include/linux/user_namespace.h b/include/linux/user_namespace.h
> index 7183e5aca282..6cc3fbec3632 100644
> --- a/include/linux/user_namespace.h
> +++ b/include/linux/user_namespace.h
> @@ -120,7 +120,7 @@ struct ucounts {
> kuid_t uid;
> atomic_t count;
> atomic_long_t ucount[UCOUNT_COUNTS];
> - atomic_long_t rlimit[UCOUNT_RLIMIT_COUNTS];
> + atomic_long_t ____cacheline_aligned_in_smp rlimit[UCOUNT_RLIMIT_COUNTS];
> };
Cute. How much bloat does it cause?
Powered by blists - more mailing lists