linux-kernel - Re: [PATCH] x86: Export tsc related information in sysfs

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: <20100516220638.2baf315d@infradead.org>
Date:	Sun, 16 May 2010 22:06:38 -0700
From:	Arjan van de Ven <arjan@...radead.org>
To:	Dan Magenheimer <dan.magenheimer@...cle.com>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Andi Kleen <andi@...stfloor.org>,
	Venkatesh Pallipadi <venki@...gle.com>,
	Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
	chris.mason@...cle.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86: Export tsc related information in sysfs

On Sun, 16 May 2010 18:31:30 -0700 (PDT)
Dan Magenheimer <dan.magenheimer@...cle.com> wrote:

> 
> It seems like the only advantages the kernel has here over
> a reasonably intelligent app is that: 1) the kernel can run
> a warp test and the app can't, and 2) the kernel can
> estimate the frequency of the TSC and the app can't.

and 3) the kernel gets thermal interrupts and the app does not
and 4) the kernel decides which power management to use when
and 5) the kernel can find out if SMI's happened, and the app cannot.
and 6) the kernel can access tsc and a per cpu offset/frequency
data atomically, without being scheduled to another CPU. The app cannot
[well it can ask the kernel to be pinned, and that's a 99.99% thing,
but still]

[snipped a bunch of twists of my argument that are not correct]

look we're not disabling ring 3 tsc. We could, but we don't.
we're just telling you that WE as kernel cannot tell you, in 
an architectural and long term (multiple kernel versions and
hardware generations) stable way, when the tsc is "usable".
Because WE know it is barely if any so. We continuously add
workarounds, calibrations and tweaks for this, and stop using it
at runtime when something smells funny and defeats our logic.

If you want to find out yourself if the tsc is good enough for you
that is one thing.... but if you want the kernel to have an official
interface for it.... the kernel has to live by that commitment.
We cannot put in that interface "oh and you need to implement the same
workarounds, scaling and offsets as the kernel does", because that's
in a huge flux, and will change from kernel version to kernel version.
The only shot you could get is some vsyscall/vdso function that gives
you a unit (but that is not easy given per cpu offset/frequency/etc..
but at least the kernel can try)

-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org
--
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/