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: <ZwatTfHxojsZwqHw@localhost.localdomain>
Date: Wed, 9 Oct 2024 18:20:29 +0200
From: Frederic Weisbecker <frederic@...nel.org>
To: Anna-Maria Behnsen <anna-maria@...utronix.de>
Cc: Thomas Gleixner <tglx@...utronix.de>, Jonathan Corbet <corbet@....net>,
	linux-kernel@...r.kernel.org, Len Brown <len.brown@...el.com>,
	"Rafael J. Wysocki" <rafael@...nel.org>,
	Michael Ellerman <mpe@...erman.id.au>,
	Nathan Lynch <nathanl@...ux.ibm.com>, linuxppc-dev@...ts.ozlabs.org
Subject: Re: [PATCH v2 13/15] powerpc/rtas: Use fsleep() to minimize
 additional sleep duration

Le Wed, Sep 11, 2024 at 07:13:39AM +0200, Anna-Maria Behnsen a écrit :
> When commit 38f7b7067dae ("powerpc/rtas: rtas_busy_delay() improvements")
> was introduced, documentation about proper usage of sleep realted functions

related*

> was outdated.
> 
> The commit message references the usage of a HZ=100 system. When using a
> 20ms sleep duration on such a system and therefore using msleep(), the
> possible additional slack will be +10ms.
> 
> When the system is configured with HZ=100 the granularity of a jiffy and of
> a bucket of the lowest timer wheel level is 10ms. To make sure a timer will
> not expire early (when queueing of the timer races with an concurrent
> update of jiffies), timers are always queued into the next bucket. This is
> the reason for the maximal possible slack of 10ms.
> 
> fsleep() limits the maximal possible slack to 25% by making threshold
> between usleep_range() and msleep() HZ dependent. As soon as the accuracy
> of msleep() is sufficient, the less expensive timer list timer based
> sleeping function is used instead of the more expensive hrtimer based
> usleep_range() function. The udelay() will not be used in this specific
> usecase as the lowest sleep length is larger than 1 microsecond.

Isn't udelay() for everything below 10us ?

> 
> Use fsleep() directly instead of using an own heuristic for the best
> sleeping mechanism to use..
> 
> Cc: Michael Ellerman <mpe@...erman.id.au>
> Cc: Nathan Lynch <nathanl@...ux.ibm.com>
> Cc: linuxppc-dev@...ts.ozlabs.org
> Signed-off-by: Anna-Maria Behnsen <anna-maria@...utronix.de>
> Acked-by: Michael Ellerman <mpe@...erman.id.au> (powerpc)

Reviewed-by: Frederic Weisbecker <frederic@...nel.org>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ