linux-kernel - Re: [PATCH v9 01/15] asm-generic: add barrier smp_cond_load_relaxed

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: <88b3b176-97c7-201e-0f89-c77f1802ffd9@gentwo.org>
Date: Fri, 8 Nov 2024 11:41:08 -0800 (PST)
From: "Christoph Lameter (Ampere)" <cl@...two.org>
To: Ankur Arora <ankur.a.arora@...cle.com>
cc: linux-pm@...r.kernel.org, kvm@...r.kernel.org, 
    linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org, 
    linux-arch@...r.kernel.org, catalin.marinas@....com, will@...nel.org, 
    tglx@...utronix.de, mingo@...hat.com, bp@...en8.de, 
    dave.hansen@...ux.intel.com, x86@...nel.org, hpa@...or.com, 
    pbonzini@...hat.com, vkuznets@...hat.com, rafael@...nel.org, 
    daniel.lezcano@...aro.org, peterz@...radead.org, arnd@...db.de, 
    lenb@...nel.org, mark.rutland@....com, harisokn@...zon.com, 
    mtosatti@...hat.com, sudeep.holla@....com, maz@...nel.org, 
    misono.tomohiro@...itsu.com, maobibo@...ngson.cn, zhenglifeng1@...wei.com, 
    joao.m.martins@...cle.com, boris.ostrovsky@...cle.com, 
    konrad.wilk@...cle.com
Subject: Re: [PATCH v9 01/15] asm-generic: add barrier
 smp_cond_load_relaxed_timeout()

On Thu, 7 Nov 2024, Ankur Arora wrote:

> > Calling the clock retrieval function repeatedly should be fine and is
> > typically done in user space as well as in kernel space for functions that
> > need to wait short time periods.
>
> The problem is that you might have multiple CPUs polling in idle
> for prolonged periods of time. And, so you want to minimize
> your power/thermal envelope.

On ARM that maps to YIELD which does not do anything for the power
envelope AFAICT. It switches to the other hyperthread.

> For instance see commit 4dc2375c1a4e "cpuidle: poll_state: Avoid
> invoking local_clock() too often" which originally added a similar
> rate limit to poll_idle() where they saw exactly that issue.

Looping w/o calling local_clock may increase the wait period etc.

For power saving most arches have special instructions like ARMS
WFE/WFET. These are then causing more accurate wait times than the looping
thing?