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: <801587.47494.qm@web25803.mail.ukl.yahoo.com>
Date:	Wed, 26 Mar 2008 08:26:01 +0100 (CET)
From:	Michael Meyer <mike65134@...oo.de>
To:	Len Brown <lenb@...nel.org>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: performance differences: "maxcpus=1" vs. "echo 0 > /sys/devices/system/cpu/cpu1/online"


--- Len Brown <lenb@...nel.org> schrieb:

> On Tuesday 25 March 2008, Michael Meyer wrote:
> > 
> > --- Andi Kleen <andi@...stfloor.org> schrieb:
> > 
> > > Luciano Rocha <luciano@...otux.com> writes:
> > > 
> > > > On Tue, Mar 25, 2008 at 02:47:50PM +0100, Michael
> > > Meyer wrote:
> > > > > Hi, 
> > > > > 
> > > > > what is the difference between booting a dual
> > > core
> > > > > machine with "maxcpus=1" or by deactivating the
> > > second
> > > > > core at run time with "echo 0 >
> > > > > /sys/devices/system/cpu/cpu1/online"?
> > > > 
> > > > maxcpus=1 should turn off the SMP alternative and
> > > switch to UP only,
> > > > optimising some locks and instructions.
> > > 
> > > CPU hot unplug will do the same. But it is unlikely
> > > it accounts
> > > for that much performance difference.
> > > 
> > > If he used maxcpus=0 it would make sense. maxcpus=0
> > > disables
> > > the IO-APIC which likely makes a large difference.
> > > But it should
> > > be actually slower.
> > > 
> > > There should be actually no difference in theory
> > > between max_cpus=1
> > > and hot unplug to one CPU. Might be some bug.
> > 
> > I had the following time values:
> > 
> > maxcpus=1:
> > real	0m1.642s
> > user	0m1.528s
> > sys	0m0.068s
> > 
> > maxcpus=2 and 
> > echo 1 > /sys/devices/system/cpu/cpu1/online:
> > real	0m2.579s
> > user	0m4.096s
> > sys	0m0.160s
> 
> this above is the baseline, yes?

Yes, it is.

> it is same as if you used no boot param
> and did not touch the online file, yes?

Yes. I just repeated it - once without the commands and once with the
same commands stated above. Same result. So this is the default.

> 
> > maxcpus=2 and
> > echo 0 > /sys/devices/system/cpu/cpu1/online:
> > real	0m3.757s
> > user	0m3.632s
> > sys	0m0.112s
> 
> Please post the contents of 
> # grep . /sys/devices/system/cpu/cpu*/cpufreq/*

# grep . /sys/devices/system/cpu/cpu*/cpufreq/*
/sys/devices/system/cpu/cpu0/cpufreq/affected_cpus:0
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq:2400000
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq:1600000
/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies:2400000
1600000 
/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors:ondemand
userspace conservative powersave performance 
/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq:1600000
/sys/devices/system/cpu/cpu0/cpufreq/scaling_driver:acpi-cpufreq
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor:ondemand
/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq:2400000
/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq:1600000
/sys/devices/system/cpu/cpu1/cpufreq/affected_cpus:1
/sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_max_freq:2400000
/sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_min_freq:1600000
/sys/devices/system/cpu/cpu1/cpufreq/scaling_available_frequencies:2400000
1600000 
/sys/devices/system/cpu/cpu1/cpufreq/scaling_available_governors:ondemand
userspace conservative powersave performance 
/sys/devices/system/cpu/cpu1/cpufreq/scaling_cur_freq:1600000
/sys/devices/system/cpu/cpu1/cpufreq/scaling_driver:acpi-cpufreq
/sys/devices/system/cpu/cpu1/cpufreq/scaling_governor:ondemand
/sys/devices/system/cpu/cpu1/cpufreq/scaling_max_freq:2400000
/sys/devices/system/cpu/cpu1/cpufreq/scaling_min_freq:1600000


> and also
> grep . /proc/acpi/processor/*/power

# grep . /proc/acpi/processor/*/power
/proc/acpi/processor/CPU0/power:active state:            C0
/proc/acpi/processor/CPU0/power:max_cstate:              C8
/proc/acpi/processor/CPU0/power:bus master activity:     00000000
/proc/acpi/processor/CPU0/power:maximum allowed latency: 8000 usec
/proc/acpi/processor/CPU0/power:states:
/proc/acpi/processor/CPU0/power:    C1:                  type[C1]
promotion[--] demotion[--] latency[000] usage[00000000]
duration[00000000000000000000]
/proc/acpi/processor/CPU1/power:active state:            C0
/proc/acpi/processor/CPU1/power:max_cstate:              C8
/proc/acpi/processor/CPU1/power:bus master activity:     00000000
/proc/acpi/processor/CPU1/power:maximum allowed latency: 8000 usec
/proc/acpi/processor/CPU1/power:states:
/proc/acpi/processor/CPU1/power:    C1:                  type[C1]
promotion[--] demotion[--] latency[000] usage[00000000]
duration[00000000000000000000]


> 
> My guess that the maxcpus=1 case benefits from turbo mode, aka EIDA.
> That benefit, however, is subject to this bug:
> http://bugzilla.kernel.org/show_bug.cgi?id=5471
> because for a single thread to run faster than the marketing MHz,
> the other thread must be in deep-idle, which is prevented
> by the bug above.
> 
> If your scaling_available_frequencies includes 2401000
> then you probably have a turbo-mode enabled processor.

It does not include 2401000. The processor is an Intel Core 2 Duo E6600
(2.4GHZ) bought at the beginning of 2007. I do not think that that kind
of freqency scaling was available back than. 

> 
> one way to verify this would be to disable turbo mode
> by pegging the MHz like so:
> 
> # echo 2400000 >
> /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq
> # echo 2400000 >
> /sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_max_freq
> 
> -Len
> 

This does not work, as both are read-only. 


      E-Mails jetzt auf Ihrem Handy.
www.yahoo.de/go

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ