linux-kernel - Re: [PATCH v2 0/1] timers/migration: add 'tmigr' kernel parameter to optionally disable timer migration

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87jz163fvq.ffs@tglx>
Date: Tue, 07 Oct 2025 17:12:25 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Sehee Jeong <sehee1.jeong@...sung.com>, anna-maria@...utronix.de,
 frederic@...nel.org, corbet@....net
Cc: linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
 sehee1.jeong@...sung.com
Subject: Re: [PATCH v2 0/1] timers/migration: add 'tmigr' kernel parameter
 to optionally disable timer migration

On Wed, Sep 10 2025 at 16:42, Sehee Jeong wrote:
> This patch introduces a kernel boot parameter to optionally disable the
> timer migration.
>
> On heterogeneous systems with big.LITTLE architectures, timer migration
> may cause timers from little cores to run on big cores, or vice versa,
> because core type differences are not considered in the current timer
> migration logic.
>
> In our heterogeneous system, we observed timers being migrated to big
> CPU frequently, resulting in timer callbacks that could have run on
> little CPUs being executed on the big CPU instead. This reduced big
> CPU's idle residency and increased overall power consumption due to
> higher power draw on the big CPU. Since timer_migration is a relatively
> new feature, addressing the structural limitation was difficult.

It's not that new, but anyway I'm not understanding what's so difficult
to address that problem in the migration code. As all of that code is
based on a hierarchy, so it requires to ensure that:

   All big CPUs are on one side of the hierarchy and all little CPUs
   on the other side and those sides are not connected.

Taking the example from the comment on top of the code:

 * LVL 2                           [GRP2:0]
 *                              GRP1:0 = GRP1:M
 *
 * LVL 1            [GRP1:0]                      [GRP1:1]
 *               GRP0:0 - GRP0:2               GRP0:3 - GRP0:5
 *
 * LVL 0  [GRP0:0]  [GRP0:1]  [GRP0:2]  [GRP0:3]  [GRP0:4]  [GRP0:5]
 * CPUS     0-7       8-15      16-23     24-31     32-39     40-47

Assume that GRP1:0 is the big cluster and GRP1:1 is the little
cluster. Then obviously LVL2 is not required for this scenario. So the
resulting hierarchy looks like this:

 * LVL 1            [GRP1:0]                      [GRP1:1]
 *               GRP0:0 - GRP0:2               GRP0:3 - GRP0:5
 *
 * LVL 0  [GRP0:0]  [GRP0:1]  [GRP0:2]  [GRP0:3]  [GRP0:4]  [GRP0:5]
 * CPUS     0-7       8-15      16-23     24-31     32-39     40-47

It works nicely even when the clusters are asymetric, i.e. one requires
more levels than the other:

 * LVL 1            [GRP1:0]                      [GRP1:1]
 *               GRP0:0		               GRP0:1 - GRP0:3
 *
 * LVL 0  [GRP0:0]                        [GRP0:1]  [GRP0:2]  [GRP0:3]
 * CPUS     0-7                             8-15      16-23     24-31 

GRP1:0 is just there to keep the code simple, but as the hierarchy ends
there it is not any different than having only CPU 8-15 online in
GRP1:1.

That means the required changes boil down to:

  1) Calculate the hierarchy levels based on big/little clusters and not
     connect those clusters on top in tmigr_init(), which means the
     hierarchy levels are one less than on a connected system.

  2) Ensure that the CPUs end up on the correct side of the hierarchy in
     tmigr_setup_groups()

  3) Prevent tmigr_cpu_offline() from assigning a cross cluster migrator.

Everything else works out of the box.

I obviously might be missing the real difficulty you observed when you
tried to address this structural "limitation". You surely can explain
that to me then, right?

> Therefore, this patch adds a boot parameter to optionally disable timer
> migration.

You still did not address my comment, that this also means that all
timers must expire on the CPU they are armed on. Which in turn causes
less idle recidency in the overall system, no?

Thanks

        tglx