linux-kernel - Re: [RFC PATCH] x86:Use cpu_khz for loops_per

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]

Date:	Thu, 05 Jun 2008 11:37:22 -0700
From:	Alok Kataria <akataria@...are.com>
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...e.hu>,
	LKML <linux-kernel@...r.kernel.org>,
	Daniel Hecht <dhecht@...are.com>, Tim Mann <mann@...are.com>,
	Zach Amsden <zach@...are.com>, Sahil Rihan <srihan@...are.com>
Subject: Re: [RFC PATCH] x86:Use cpu_khz for loops_per_jiffy calculation

On Wed, 2008-06-04 at 06:16 -0700, Arjan van de Ven wrote:
> On Tue, 3 Jun 2008 21:01:54 -0700
> "Alok kataria" <alokkataria1@...il.com> wrote:
> 
> > On Tue, Jun 3, 2008 at 6:20 PM, Arjan van de Ven
> > <arjan@...radead.org> wrote:
> > > On Tue, 03 Jun 2008 17:41:09 -0700
> > > Alok Kataria <akataria@...are.com> wrote:
> > >
> > >> On X86 platform we can use the value of cpu_khz computed during tsc
> > >> calibration to calculate the loops_per_jiffy value. Its very
> > >> important to keep the error in lpj values to minimum as any error
> > >> in that may result in kernel panic in check_timer.
> > >> In virtualization environment on a highly overloaded host, the
> > >> guest delay calibration may sometimes result in errors beyond the
> > >> ~50% that timer_irq_works can handle, resulting in the guest
> > >> panicking.
> > > \
> > >
> > > can you guarantee that the rate tsc ticks at is the same as the
> > > current CPU frequency? Answer: You can't....
> > >
> >
> > I think at the boot time atleast we can assume that, no ?
> 
> Nope, absolutely not.
> 1) The rate TSC ticks may or may not be the maximum frequency (usually
> is, but no guarantee)
> 2) The BIOS might not boot your system at the maximum frequency (think
> "laptop on battery")... that's really up to the BIOS.
> 

So then, how about using the tsc_khz (tsc frequency) for this
calculation. Atleast for the boot processor the lpj value can be derived
from the tsc frequency.
So insted of using lpj_tsc for all cpu's we can use it just for the boot
processor.

> >
> > > sadly we do need to calibrate this...
> > >
> > > In addition, clearly you can have different cpus in a system run at
> > > a different rate (both in terms of cpu_khz and, independently, in
> > > terms of tsc rate)
> > >
> >
> > Again yes at run time frequency's may change but they shouldn't at
> > boottime. AFAIK, i don't think there are X86 MP systems with
> > asymmetric cpus i.e. systems with different
> > base frequencies. If thats not true then there sure is a problem.
> 
> there's nothing that guarantees this. (Well maybe Dell's website does
> because they want to sell you 2 expensive cpus rather than 1 cheap 1
> expensive one ;-)

Agreed so we might not be able to use it for other cpus's. 
Is there a way to get the cpu frequency of the processor that we are
bringing up, i see that there is cpufreq_quick_get but this would be
initialized very late in the boot process.  

If there is a way we can check if the cpu being brought up is same as
the last one and then we can skip the delay calibration, something like
what ia64 does.

Thanks,
Alok

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