linux-kernel - Re: [RESEND PATCH v2 2/2] power/idle: enhance the precision of sleep

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: <CAN2waFsnAUExsAhCgtTLcxYrxVuBL+TfFA0viOhk-9WGFnwnhQ@mail.gmail.com>
Date:	Thu, 23 Jun 2016 16:45:29 +0800
From:	Zhaoyang Huang <zhaoyang.huang@...aro.org>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	Daniel Lezcano <daniel.lezcano@...aro.org>,
	Geng Ren <geng.ren@...eadtrum.com>,
	Alex Wang <alex.wang@...eadtrum.com>,
	Vincent Guittot <vincent.guittot@...aro.org>,
	linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
	mingo@...hat.com, peterz@...radead.org,
	Zhaoyang Huang (黄朝阳) 
	<zhaoyang.huang@...eadtrum.com>,
	Serge Broslavsky <serge.broslavsky@...aro.org>
Subject: Re: [RESEND PATCH v2 2/2] power/idle: enhance the precision of sleep_length

On 23 June 2016 at 16:35, Thomas Gleixner <tglx@...utronix.de> wrote:
> On Thu, 23 Jun 2016, Zhaoyang Huang wrote:
>> On 23 June 2016 at 16:18, Thomas Gleixner <tglx@...utronix.de> wrote:
>> > On Thu, 23 Jun 2016, Zhaoyang Huang wrote:
>> >> On 23 June 2016 at 15:01, Thomas Gleixner <tglx@...utronix.de> wrote:
>> >> Thomas, I agree with you, I have discussed the modification with the
>> >> call back owner. However, I wonder if we can make the idle's framework
>> >> to be more precised without the assumption of short CPU_PM_ENTER
>> >> callbacks. Thank you!
>> >
>> > What's the point? To help people who put insanities into the idle code path?
>> >
>> > Thanks,
>> >
>> >         tglx
>> >
>> Hi, Thomas. If the entry,exit,min time of one idle state sums up to
>> 500us in some platform, the 100us callback which should be common as
>> caused by cache miss would also generate 20% imprecision. Don't you
>
> A cache miss is causing a 100us callback? What are you talking about?
>
> Thanks,
>
>         tglx
By a serials of memory access which maybe missed on cache all. Anyway,
we can require the callback not to introduce schedule etc, but can not
ask them to ensure their own executing time, which they can not
control.