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  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 23 Jan 2017 13:50:25 +0100
From:   Daniel Lezcano <>
To:     Alex Shi <>
Cc:     "Rafael J. Wysocki" <>,
        Greg Kroah-Hartman <>,
        "Rafael J . Wysocki" <>,
        Vincent Guittot <>,
        Linux PM <>,
        Linux Kernel Mailing List <>,
        Ulf Hansson <>,
        Rasmus Villemoes <>,
        Arjan van de Ven <>,
        Rik van Riel <>
Subject: Re: [PATCH 3/3] cpuidle/menu: add per cpu pm_qos_resume_latency

On Sun, Jan 22, 2017 at 09:31:44AM +0800, Alex Shi wrote:
> >Yeah, that could be problematic. The code snippet gives the general idea but it
> >could be changed by for example by a flag telling the cpus when they enter idle
> >to update their state_count. Or something like that.
> Yes, this idea could be helpful.
> But since the idle path isn't a hot path. and a few memory access won't cost
> a lot. So I doubt if the benefit could be measurable.

It won't be measurable, as well as reading the cpu device latency before
checking the latency req is zero, but it makes sense.

The idle routine is not a hot path but a very special place where the interrupt
are disabled, the rcu is not usable, tick is disabled etc ...

Perhaps it is not a problem for the moment, but it is probably worth to mention that
using API from other subsystems in the idle select path could be problematic
and perhaps it is time to think about another approach for the future.


 <> │ Open source software for ARM SoCs

Follow Linaro:  <> Facebook |
<!/linaroorg> Twitter |
<> Blog

Powered by blists - more mailing lists