linux-kernel - Re: [PATCH] Option to disable AMD C1E (allows dynticks to work)

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: <20071230231208.0c766258@linux360.ro>
Date:	Sun, 30 Dec 2007 23:12:08 +0200
From:	Eduard-Gabriel Munteanu <eduard.munteanu@...ux360.ro>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	pharon@...il.com, Rene Herman <rene.herman@...access.nl>,
	"David P. Reed" <dpreed@...d.com>,
	Richard Harman <richard@...hardharman.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...hat.com>
Subject: Re: [PATCH] Option to disable AMD C1E (allows dynticks to work)

On Sun, 30 Dec 2007 15:42:17 +0100
Andi Kleen <andi@...stfloor.org> wrote:

> Eduard-Gabriel Munteanu <eduard.munteanu@...ux360.ro> writes:
> >
> > Other kernel developers, as discussed previously in this thread, are
> > working on a HPET-driven dynticks (as opposed to the current
> > LAPIC-driven one), but the change isn't that easy to make.
> 
> No, actually HPET based dyntick has been implemented for a long time
> (as long as APIC based dyntick). APIC based dyntick is preferred 
> because it is a little cheaper, but both are there.
> 
> The problem is just that many BIOSes don't tell the kernel about the
> HPET location (even when the chipset supports it) because that wasn't
> needed for older Windows versions.  And without the BIOS telling the
> kernel HPET it doesn't know where it is and can't use it when
> the APIC timer is not usable.
> 
> The ongoing work is to implement hpet=force code that knows
> about various chipsets and reads their hardware registers directly
> and then uses the HPET timer without BIOS support.

As far as I can see, the kernel doesn't behave as it would be, IMO,
normal. I do have HPETs and Linux detects them without any
need for hpet=force (HPET is registered for clockevents), but keeps
LAPIC as the only option for dynticks. It looks like timing devices are
rated and then only one of them is selected for dynticks. But when that
one (here LAPIC) fails to provide the required functionality for nohz,
Linux does not fallback to the next best timer, as dynticks is provided
with only one such device, hence the message "lapic is not functional"
is shown. In fact, this selection process should be fixed.

Before coding my patch, I tried fiddling with that rating algorithm,
but Linux kept locking up during boot. I'll try again, maybe my
approach wasn't correct, but please tell me: is HPET-driven dynticks
code working? (I'm quite confused, as HPET should wake the CPUs even
when in C1E.)

> > This way,
> > dynticks and C1E could be both enabled and thus save more power.
> 
> I would not expect too much over a HZ=100 kernel on current AMD. 

With my patch (the one that disables C1E), powertop shows at most 10-11
wakeups per second when idle (no X server running). Isn't it
reasonable to expect a significant improvement over HZ=100?

--
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/