> Date: Mon, 04 May 2009 15:24:27 +0300 > From: Alexander Motin <mav_at_FreeBSD.org> > Sender: owner-freebsd-mobile_at_freebsd.org > > Alexandre "Sunny" Kovalenko wrote: > > On Mon, 2009-05-04 at 01:18 +0300, Alexander Motin wrote: > >> - C3 state allows CPU completely stop all internal clocks, reduce > >> voltage and disconnect from system bus. This state gives additional > >> power saving effect, but it is not cheap and require trade-offs. > >> As soon as CPU is completely stopped in C3 state, local APIC timers in > >> each CPU core, used by FreeBSD as event sources on SMP, are not > >> functioning. It stops system time, breaks scheduling that makes system > >> close to dead. > > Did you try to see whether putting one of the cores in C3 state by doing > > something like > > > > dev.cpu.1.cx_lowest=C3 > > > > makes any difference? > > > > # sysctl dev.cpu | grep cx_usage > > dev.cpu.0.cx_usage: 0.00% 100.00% 0.00% > > dev.cpu.1.cx_usage: 0.00% 5.18% 94.81% > > I did. As soon as first CPU core is not in C3 state, second core unable > to enter C3 completely and disconnect from the bus, as cores are sharing > common resources. Such technique allows to avoid LAPIC timer problems, > but I haven't noticed any effect from this on CPU idle power. The only > difference I have noticed was in the case, when first core is busy. C3 > on second idle core then somehow reduces summary consumption a bit. > > In other words, C3 state should be active on both cores simultaneously > to give real effect. It is important to be aware that the presence of USB will keep a system from entering C3. Either build a kernel without USB and load it only whan needed or run 8-CURRENT with the USB2 stack which is purported to fix this problem. (I have no systems running CURRENT, so I can't confirm that USB2 fixes the problem.) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman_at_es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751Received on Mon May 04 2009 - 13:10:01 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:47 UTC