linux-kernel - Re: [RFC PATCH 2/4] x86, mwaitt: introduce mwaitx idle with a configurable timer

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: <20150520091213.GA3645@pd.tnic>
Date:	Wed, 20 May 2015 11:12:13 +0200
From:	Borislav Petkov <bp@...e.de>
To:	Ingo Molnar <mingo@...nel.org>, Huang Rui <ray.huang@....com>
Cc:	Len Brown <lenb@...nel.org>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Thomas Gleixner <tglx@...utronix.de>, x86@...nel.org,
	linux-kernel@...r.kernel.org,
	Fengguang Wu <fengguang.wu@...el.com>,
	Aaron Lu <aaron.lu@...el.com>, Tony Li <tony.li@....com>
Subject: Re: [RFC PATCH 2/4] x86, mwaitt: introduce mwaitx idle with a
 configurable timer

On Wed, May 20, 2015 at 10:55:20AM +0200, Ingo Molnar wrote:
> Does it use it to decide how 'deep' a sleep it will go into, i.e. 
> larger timeouts cause longer entry and exit latencies?

That's what the HLT thing does. Cores go into C1 and then at some point
(hysteresis, etc) the whole core complex enters C1E.

The MWAIT* should be used for only shorter sleeps as it remains in C1.
IMHO, of course.

But the problem there is another: what happens if the timeout fires,
you wake up and see that you can remain idle? Do HLT? Do another MWAITX
round?

This means you have an additional unnecessary wakeup which costs.

> I suppose it's also the case that if an interrupt arrives _before_ the 
> expected timeout then MWAITX will try to exit immediately, it won't 
> wait until the timeout, right?

I'd assume so - I mean, it must, right.

BUT!, in talking to Andy about it last night on IRC, he pointed out
that when using acpi_idle, we never come to calling x86_idle() and from
looking quickly at cpuidle_idle_call(), that still might be the case as
we go to use_default only when there's an error with the cpuidle driver
or so.

So Rui, before you go and do more work on it, you should probably
analyze what cpuidle exactly does (if you haven't done so yet). And on
AMD we do use acpi_idle - at least on my F15h box that is the case:

$ grep . /sys/devices/system/cpu/cpuidle/current_*
/sys/devices/system/cpu/cpuidle/current_driver:acpi_idle
/sys/devices/system/cpu/cpuidle/current_governor_ro:menu

Thanks.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/