Re: CPU Frequencies Don't scale independently
On Mon, 30 Jun 2008 17:56:44 -0300 Eduardo M KALINOWSKI [EMAIL PROTECTED] wrote: charlie derr escreveu: Jochen Schulz wrote: Hakan BAYINDIR: P.S. I cannot send a config.gz since the kernel is prepackaged. You'll find the configuration of the currently running kernel in /proc/config.gz. At least Debian kernels have that feature enabled by default. J. It would sure be nice if that were the case, but I don't think it's true. I have linux-image-2.6.25-2-686 installed from the debian package (in sid) and I'm booted into it, but there's no config.gz in /proc I never heard of kernel configs in /proc, after all, /proc is a pseudo filesystem. But try looking in /boot. For the record, /boot/config-whatever is a config file placed there during the installation of the kernel, and there will generally be one for every kernel installed on the system. /proc/config.gz is the currently running kernel's exported version of its config; it will apparently appear if 'General Setup/Kernel .config support' and 'Enable access to .config through /proc/config.gz' (below the former option) are enabled in the kernel config. I don't enable them, since the /boot version is fine for me. Celejar -- mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
{SOLVED} Re: CPU Frequencies Don't scale independently
Volkan YAZICI wrote: On Tue, 01 Jul 2008, Hakan BAYINDIR [EMAIL PROTECTED] writes: # # CPU Frequency scaling # CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_TABLE=m # CONFIG_CPU_FREQ_DEBUG is not set CONFIG_CPU_FREQ_STAT=m # CONFIG_CPU_FREQ_STAT_DETAILS is not set CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=m CONFIG_CPU_FREQ_GOV_USERSPACE=m CONFIG_CPU_FREQ_GOV_ONDEMAND=m CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m # # CPUFreq processor drivers # CONFIG_X86_ACPI_CPUFREQ=m CONFIG_X86_POWERNOW_K6=m CONFIG_X86_POWERNOW_K7=m CONFIG_X86_POWERNOW_K7_ACPI=y CONFIG_X86_POWERNOW_K8=m CONFIG_X86_POWERNOW_K8_ACPI=y CONFIG_X86_GX_SUSPMOD=m CONFIG_X86_SPEEDSTEP_CENTRINO=m CONFIG_X86_SPEEDSTEP_CENTRINO_TABLE=y CONFIG_X86_SPEEDSTEP_ICH=m CONFIG_X86_SPEEDSTEP_SMI=m CONFIG_X86_P4_CLOCKMOD=m CONFIG_X86_CPUFREQ_NFORCE2=m CONFIG_X86_LONGRUN=m CONFIG_X86_LONGHAUL=m CONFIG_X86_E_POWERSAVER=m Also lsmod output will be helpful as well. Regards. After subscribing to cpu-freq mailing list and asking the same question here, Venkatesh Pallipadi from intel answered my question. He said that since voltages in a CPU package is constant across cores, keeping frequencies low on other cores while clocking one up doesn't save considerable amount of power. Because of this fact, they keep the frequencies in a core synchronized if possible. Since his message is more informational than that, I'm quoting information parts from the conversation below: In actual hardware, voltage is coordinated at socket level and that is the reason frequencies in one socket are tied together. Now, what has changed in two above config will be the mode in which kernel operates: 1) Hardware coordination mode: Kernel thinks each core is having independent frequency and reports the same. Underneath, hardware does frequency coodination and picks the highest requested frequency among all cores and runs all cores at that freq. 2) Software coordination mode: Kernel understands which specific CPUs are dependent and picks the highest frequency needed among all such dependent cores and makes single request for such frequency and reports the same. Note that there should not be any power consumption difference with these two kernels on under identical load. Just that the kernel now knows more about the frequency dependencies in the platform. and Both Core 2 Duo and Core 2 Quad, voltage is sync'ed across all cores in a single socket due to VR restriction. Most of the power savings from lower freq comes from lower voltage. As all cores in a single socket runs on same voltage here, independent voltage is not possible. On a real multi-socket system (dual or quad socket serves, cores in each socket can be at different frequencies though). Older linux kernel only supports hardware coordination which explains the pre 2.6.21 behavior. Newer Linux kernel picks up hardware coordination mode or software coordination mode based on depending on BIOS capability and information it gets from BIOS ACPI table. So, it is possible that different systems have different coordination mode active, with same kernel. Thanks to all for your help and time, Cheers and Regards, --Hakan P.S: For reference, my PC configuration is below: CPU: Intel Core2Quad Q6600, 2.4GHz M/B: MSI P35 Platinum, BIOS ver. 1.8 RAM: 4GB OCz Flex XLC CL3 DDR2 Distro: Debian testing Kernel: 2.6.24-1-686-bigmem signature.asc Description: OpenPGP digital signature
Re: {SOLVED} Re: CPU Frequencies Don't scale independently
Hakan BAYINDIR wrote: Volkan YAZICI wrote: On Tue, 01 Jul 2008, Hakan BAYINDIR [EMAIL PROTECTED] writes: # # CPU Frequency scaling # CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_TABLE=m # CONFIG_CPU_FREQ_DEBUG is not set CONFIG_CPU_FREQ_STAT=m # CONFIG_CPU_FREQ_STAT_DETAILS is not set CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=m CONFIG_CPU_FREQ_GOV_USERSPACE=m CONFIG_CPU_FREQ_GOV_ONDEMAND=m CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m # # CPUFreq processor drivers # CONFIG_X86_ACPI_CPUFREQ=m CONFIG_X86_POWERNOW_K6=m CONFIG_X86_POWERNOW_K7=m CONFIG_X86_POWERNOW_K7_ACPI=y CONFIG_X86_POWERNOW_K8=m CONFIG_X86_POWERNOW_K8_ACPI=y CONFIG_X86_GX_SUSPMOD=m CONFIG_X86_SPEEDSTEP_CENTRINO=m CONFIG_X86_SPEEDSTEP_CENTRINO_TABLE=y CONFIG_X86_SPEEDSTEP_ICH=m CONFIG_X86_SPEEDSTEP_SMI=m CONFIG_X86_P4_CLOCKMOD=m CONFIG_X86_CPUFREQ_NFORCE2=m CONFIG_X86_LONGRUN=m CONFIG_X86_LONGHAUL=m CONFIG_X86_E_POWERSAVER=m Also lsmod output will be helpful as well. Regards. After subscribing to cpu-freq mailing list and asking the same question here, Venkatesh Pallipadi from intel answered my question. He said that since voltages in a CPU package is constant across cores, keeping frequencies low on other cores while clocking one up doesn't save considerable amount of power. Because of this fact, they keep the frequencies in a core synchronized if possible. Since his message is more informational than that, I'm quoting information parts from the conversation below: In actual hardware, voltage is coordinated at socket level and that is the reason frequencies in one socket are tied together. Now, what has changed in two above config will be the mode in which kernel operates: 1) Hardware coordination mode: Kernel thinks each core is having independent frequency and reports the same. Underneath, hardware does frequency coodination and picks the highest requested frequency among all cores and runs all cores at that freq. 2) Software coordination mode: Kernel understands which specific CPUs are dependent and picks the highest frequency needed among all such dependent cores and makes single request for such frequency and reports the same. Note that there should not be any power consumption difference with these two kernels on under identical load. Just that the kernel now knows more about the frequency dependencies in the platform. and Both Core 2 Duo and Core 2 Quad, voltage is sync'ed across all cores in a single socket due to VR restriction. Most of the power savings from lower freq comes from lower voltage. As all cores in a single socket runs on same voltage here, independent voltage is not possible. On a real multi-socket system (dual or quad socket serves, cores in each socket can be at different frequencies though). Older linux kernel only supports hardware coordination which explains the pre 2.6.21 behavior. Newer Linux kernel picks up hardware coordination mode or software coordination mode based on depending on BIOS capability and information it gets from BIOS ACPI table. So, it is possible that different systems have different coordination mode active, with same kernel. Thanks to all for your help and time, Cheers and Regards, --Hakan P.S: For reference, my PC configuration is below: CPU: Intel Core2Quad Q6600, 2.4GHz M/B: MSI P35 Platinum, BIOS ver. 1.8 RAM: 4GB OCz Flex XLC CL3 DDR2 Distro: Debian testing Kernel: 2.6.24-1-686-bigmem Umm a last, small clarification: It seems like Core series CPUs cannot scale their cores independently and this was an illusion I saw from kernel behavior. After reading the conversation again, I got it completely. Thanks again. Cheers, --Hakan. signature.asc Description: OpenPGP digital signature
Re: {SOLVED} Re: CPU Frequencies Don't scale independently
Hakan BAYINDIR: After subscribing to cpu-freq mailing list and asking the same question here, Venkatesh Pallipadi from intel answered my question. He said that since voltages in a CPU package is constant across cores, keeping frequencies low on other cores while clocking one up doesn't save considerable amount of power. Because of this fact, they keep the frequencies in a core synchronized if possible. Thanks a lot for reporting your findings. This is very interesting. Finally I can say I learnt something today. :) J. -- Scientists know what they are talking about. [Agree] [Disagree] http://www.slowlydownward.com/NODATA/data_enter2.html signature.asc Description: Digital signature
Re: {SOLVED} Re: CPU Frequencies Don't scale independently
Jochen Schulz wrote: Hakan BAYINDIR: After subscribing to cpu-freq mailing list and asking the same question here, Venkatesh Pallipadi from intel answered my question. He said that since voltages in a CPU package is constant across cores, keeping frequencies low on other cores while clocking one up doesn't save considerable amount of power. Because of this fact, they keep the frequencies in a core synchronized if possible. Thanks a lot for reporting your findings. This is very interesting. Finally I can say I learnt something today. :) J. You are welcome :) Btw, after that mail, There's a clarification of mine. I recommend reading that too. To be honest, I've learned something too and I like this feeling. Cheers, --Hakan. signature.asc Description: OpenPGP digital signature
Re: {SOLVED} Re: CPU Frequencies Don't scale independently
On Tue, 01 Jul 2008, Hakan BAYINDIR [EMAIL PROTECTED] writes: After subscribing to cpu-freq mailing list and asking the same question here, Venkatesh Pallipadi from intel answered my question. For the records: http://article.gmane.org/gmane.linux.kernel.cpufreq/6441 Regards. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CPU Frequencies Don't scale independently
Hi, On Sun, 29 Jun 2008, Hakan BAYINDIR [EMAIL PROTECTED] writes: I'm running debian testing on a Intel Core2Quad Q6600 CPU with 4 gigabytes of RAM for 7 months. Until 2.6.22, the kernel was scaling each of my cores independently of each other but starting with 2.6.22, every core is running in the same frequency. While this doesn't pose any stability or performance issues, causes higher temprature and noise when I run a single threaded computing intensive job. I tracked the cause a bit. I was able to dig upto /sys/devices/system/cpu/cpuX/cpufreq/affected_cpus. This file says which CPUs should scale together. Since file is read only even to root I think it's an unconfigurable option. I also found that cpu frequencies are adjusted by cpufreq_acpi module and I cannot find any configuration related to it files in my system (with my current knowledge). The weird thing is I'm running an exact clone of this system in my office with a core2duo system which scales its cores independently. I cloned my home system to the office when I was running an Athlon64, approximately 1.5 years ago. If anybody can say what is wrong, is it the expected behavior, where should I look further, or whom I can talk to? BTW, I'm running 2.6.24-1-686-bigmem kernel prepackaged from debian testing. Did you solve your problem? I may recommend you to read files under linux/Documentation/cpu-freq directory. BTW, sending your /proc/config.gz might be helpful. Regards. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CPU Frequencies Don't scale independently
Volkan YAZICI wrote: Hi, On Sun, 29 Jun 2008, Hakan BAYINDIR [EMAIL PROTECTED] writes: I'm running debian testing on a Intel Core2Quad Q6600 CPU with 4 gigabytes of RAM for 7 months. Until 2.6.22, the kernel was scaling each of my cores independently of each other but starting with 2.6.22, every core is running in the same frequency. While this doesn't pose any stability or performance issues, causes higher temprature and noise when I run a single threaded computing intensive job. I tracked the cause a bit. I was able to dig upto /sys/devices/system/cpu/cpuX/cpufreq/affected_cpus. This file says which CPUs should scale together. Since file is read only even to root I think it's an unconfigurable option. I also found that cpu frequencies are adjusted by cpufreq_acpi module and I cannot find any configuration related to it files in my system (with my current knowledge). The weird thing is I'm running an exact clone of this system in my office with a core2duo system which scales its cores independently. I cloned my home system to the office when I was running an Athlon64, approximately 1.5 years ago. If anybody can say what is wrong, is it the expected behavior, where should I look further, or whom I can talk to? BTW, I'm running 2.6.24-1-686-bigmem kernel prepackaged from debian testing. Did you solve your problem? I may recommend you to read files under linux/Documentation/cpu-freq directory. BTW, sending your /proc/config.gz might be helpful. Regards. Hi, I was unable to solve my problem so, I got the source of the kernel I'm using from Debian with apt-source. The cpu_freq dcoumentation doesn't show affected_cpus in the interface so it's unconfigurable as I guessed. So I found cpu-freq mailing list from the docs and I think I'll continue digging from there. But first, I'll try with an ubuntu live CD to verify behavior. Cheers and Regards, --Hakan. P.S. I cannot send a config.gz since the kernel is prepackaged. signature.asc Description: OpenPGP digital signature
Re: CPU Frequencies Don't scale independently
Hakan BAYINDIR: P.S. I cannot send a config.gz since the kernel is prepackaged. You'll find the configuration of the currently running kernel in /proc/config.gz. At least Debian kernels have that feature enabled by default. J. -- Looking into my eyes is the only way you'll know I'm telling the truth. [Agree] [Disagree] http://www.slowlydownward.com/NODATA/data_enter2.html signature.asc Description: Digital signature
Re: CPU Frequencies Don't scale independently
Jochen Schulz wrote: Hakan BAYINDIR: P.S. I cannot send a config.gz since the kernel is prepackaged. You'll find the configuration of the currently running kernel in /proc/config.gz. At least Debian kernels have that feature enabled by default. J. Unfortunately this is not the case with 2.6.24-1-686-bigmem. Attached is my /proc listing from the view perspective of root user. Cheers, --Hakan 1 10 11 1182 12 1262 13 14 15 153 16 17 18 19 1949 1968 1969 2 2004 201 202 203 204 205 206 207 25240 25250 2612 2613 2614 26824 26945 3 3375 3444 3456 3752 3753 3754 3756 3831 3839 4 4029 4038 4050 4113 4123 4398 4415 4421 4446 4447 4449 4450 4481 4482 4483 4484 4485 4486 4487 4488 4489 4490 4494 4504 4516 4519 4556 4557 4565 4566 4576 4577 4588 4589 4610 4617 4618 4623 4635 4642 4658 4675 4682 4701 4737 4741 4760 4761 4762 4763 4764 4765 4776 4803 4836 4839 4840 4871 4872 4875 4877 4879 4901 4903 4904 4905 4907 4909 4912 4931 4933 4935 4937 4939 4940 4942 4944 4961 4966 4967 4978 4983 4986 4987 4988 4990 4995 4996 5 5092 5095 5096 52 5251 53 5320 54 55 5621 5633 5638 5645 58 59 6 603 604 7 8 811 812 813 814 815 9 904 905 935 948 949 992 993 acpi asound buddyinfo bus cgroups cmdline cpuinfo crypto devices diskstats dma driver execdomains fb filesystems fs ide interrupts iomem ioports irq kallsyms kcore key-users kmsg loadavg locks meminfo misc modules mounts mtrr net pagetypeinfo partitions scsi self slabinfo stat swaps sys sysrq-trigger sysvipc timer_list timer_stats tty uptime version vmstat zoneinfo signature.asc Description: OpenPGP digital signature
Re: CPU Frequencies Don't scale independently
Hakan BAYINDIR: Jochen Schulz wrote: Hakan BAYINDIR: P.S. I cannot send a config.gz since the kernel is prepackaged. You'll find the configuration of the currently running kernel in /proc/config.gz. At least Debian kernels have that feature enabled by default. Unfortunately this is not the case with 2.6.24-1-686-bigmem. Strange. linux-image-2.6.25-2-amd6 has it. J. -- If I was Mark Chapman I would have shot John Lennon with a water pistol. [Agree] [Disagree] http://www.slowlydownward.com/NODATA/data_enter2.html signature.asc Description: Digital signature
Re: CPU Frequencies Don't scale independently
Jochen Schulz wrote: Hakan BAYINDIR: P.S. I cannot send a config.gz since the kernel is prepackaged. You'll find the configuration of the currently running kernel in /proc/config.gz. At least Debian kernels have that feature enabled by default. J. It would sure be nice if that were the case, but I don't think it's true. I have linux-image-2.6.25-2-686 installed from the debian package (in sid) and I'm booted into it, but there's no config.gz in /proc ~c -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CPU Frequencies Don't scale independently
charlie derr escreveu: Jochen Schulz wrote: Hakan BAYINDIR: P.S. I cannot send a config.gz since the kernel is prepackaged. You'll find the configuration of the currently running kernel in /proc/config.gz. At least Debian kernels have that feature enabled by default. J. It would sure be nice if that were the case, but I don't think it's true. I have linux-image-2.6.25-2-686 installed from the debian package (in sid) and I'm booted into it, but there's no config.gz in /proc I never heard of kernel configs in /proc, after all, /proc is a pseudo filesystem. But try looking in /boot. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CPU Frequencies Don't scale independently
charlie derr escreveu: Jochen Schulz wrote: Hakan BAYINDIR: P.S. I cannot send a config.gz since the kernel is prepackaged. You'll find the configuration of the currently running kernel in /proc/config.gz. At least Debian kernels have that feature enabled by= default. J. It would sure be nice if that were the case, but I don't think it's true. I have linux-image-2.6.25-2-686 installed from the debian package (in sid) and I'm booted into it, but there's no config.gz in /proc I never heard of kernel configs in /proc, after all, /proc is a pseudo filesystem. But try looking in /boot. Yepp the config is under /boot with the name config-kernelpackagename. signature.asc Description: OpenPGP digital signature
Re: CPU Frequencies Don't scale independently
On Mon, Jun 30, 2008 at 23:41:26 +0300, Hakan BAYINDIR wrote: Jochen Schulz wrote: Hakan BAYINDIR: P.S. I cannot send a config.gz since the kernel is prepackaged. You'll find the configuration of the currently running kernel in /proc/config.gz. At least Debian kernels have that feature enabled by default. J. Unfortunately this is not the case with 2.6.24-1-686-bigmem. Attached is my /proc listing from the view perspective of root user. Check if you have the file /boot/config-2.6.24-1-686-bigmem. -- Regards,| http://users.icfo.es/Florian.Kulzer Florian | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CPU Frequencies Don't scale independently
On Tue, 01 Jul 2008, Hakan BAYINDIR [EMAIL PROTECTED] writes: Yepp the config is under /boot with the name config-kernelpackagename. So? Can we see it, please? Regards. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CPU Frequencies Don't scale independently
On Tue, 01 Jul 2008, Hakan BAYINDIR [EMAIL PROTECTED] writes: # # CPU Frequency scaling # CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_TABLE=m # CONFIG_CPU_FREQ_DEBUG is not set CONFIG_CPU_FREQ_STAT=m # CONFIG_CPU_FREQ_STAT_DETAILS is not set CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=m CONFIG_CPU_FREQ_GOV_USERSPACE=m CONFIG_CPU_FREQ_GOV_ONDEMAND=m CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m # # CPUFreq processor drivers # CONFIG_X86_ACPI_CPUFREQ=m CONFIG_X86_POWERNOW_K6=m CONFIG_X86_POWERNOW_K7=m CONFIG_X86_POWERNOW_K7_ACPI=y CONFIG_X86_POWERNOW_K8=m CONFIG_X86_POWERNOW_K8_ACPI=y CONFIG_X86_GX_SUSPMOD=m CONFIG_X86_SPEEDSTEP_CENTRINO=m CONFIG_X86_SPEEDSTEP_CENTRINO_TABLE=y CONFIG_X86_SPEEDSTEP_ICH=m CONFIG_X86_SPEEDSTEP_SMI=m CONFIG_X86_P4_CLOCKMOD=m CONFIG_X86_CPUFREQ_NFORCE2=m CONFIG_X86_LONGRUN=m CONFIG_X86_LONGHAUL=m CONFIG_X86_E_POWERSAVER=m Also lsmod output will be helpful as well. Regards. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
