linux-kernel - Re: [RFC 2/2] Make x86 calibrate

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, 31 Mar 2011 04:37:23 -0500
From:	Robin Holt <holt@....com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Yinghai Lu <yinghai@...nel.org>, Robin Holt <holt@....com>,
	Andi Kleen <andi@...stfloor.org>, linux-kernel@...r.kernel.org,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>
Subject: Re: [RFC 2/2] Make x86 calibrate_delay run in parallel.

On Thu, Mar 31, 2011 at 08:58:05AM +0200, Ingo Molnar wrote:
> 
> * Ingo Molnar <mingo@...e.hu> wrote:
> 
> > 
> > * Yinghai Lu <yinghai@...nel.org> wrote:
> > 
> > > On Tue, Dec 14, 2010 at 5:58 PM,  <Robin@....com> wrote:
> > > >
> > > > On a 4096 cpu machine, we noticed that 318 seconds were taken for bringing
> > > > up the cpus.  By specifying lpj=<value>, we reduced that to 75 seconds.
> > > > Andi Kleen suggested we rework the calibrate_delay calls to run in
> > > > parallel.  With that code in place, a test boot of the same machine took
> > > > 61 seconds to bring the cups up.  I am not sure how we beat the lpj=
> > > > case, but it did outperform.
> > > >
> > > > One thing to note is the total BogoMIPS value is also consistently higher.
> > > > I am wondering if this is an effect with the cores being in performance
> > > > mode.  I did notice that the parallel calibrate_delay calls did cause the
> > > > fans on the machine to ramp up to full speed where the normal sequential
> > > > calls did not cause them to budge at all.
> > > 
> > > please check attached patch, that could calibrate correctly.
> > > 
> > > Thanks
> > > 
> > > Yinghai
> > 
> > > [PATCH -v2] x86: Make calibrate_delay run in parallel.
> > > 
> > > On a 4096 cpu machine, we noticed that 318 seconds were taken for bringing
> > > up the cpus.  By specifying lpj=<value>, we reduced that to 75 seconds.
> > > Andi Kleen suggested we rework the calibrate_delay calls to run in
> > > parallel.
> > 
> > The risk wit that suggestion is that it will spectacularly miscalibrate on 
> > hyperthreading systems.

I am not trying to be argumentative.  I never got an understanding of
what was going wrong with that earlier patch and am hoping for some
understanding now.

Why does it spectacularly miscalibrate?  Can anything be done to correct
that miscalibration?  Doesn't this patch indicate another problem with
the calibration for hotplug cpus?  Isn't there already a problem if
you boot a cpu normally, then hot-remove a hyperthread of a cpu, run a
userland task which fully loads up all the cores on that socket, then
hot-add that hyperthread back in?  If the lpj value is that volatile,
what value does it really have?

Thank you for your insights,
Robin
--
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/