Re: Fighting for the power.

Nate Lawson wrote:
> The time may have come to disable p4tcc and throttling by default, as
> long as it's easy for a user to enable them again. Perhaps just a change
> to boot/default/device.hints?

They still could be effective for old P4 series which had no C1E/C2 idle 
states support yet. But probably their power consumption is not so 
interesting area now.

> The default settings in rc.conf should allow the lowest Cx setting
> available to be used. Perhaps that changed? Really, we want C3+ to be
> enabled by default without the user doing anything.

Present defaults are to use C1. Probably we can allow C2 use more or 
less safely. Due to default LAPIC timer problems, enabling C3+ by 
default will make system dead by default.

> Yeah, hz=1000 doesn't make sense for laptops and I use hz=100 everywhere.

Without using C3+ it is not so important. I haven't seen any power 
difference. C1/C2 have practically zero exit latency, while power 
consumed by interrupt handler itself is miserable.

> The real solution for C3 (and C4, etc.) is to implement tickless
> scheduling and to fix the current dependence on LAPIC for timer
> interrupts. Hopefully someone will do that soon. With that change, this
> change isn't needed.

System will always have tons of waiting callouts and timeouts to be 
handled. So timer will be always needed. Working timer.

>> 4. HDA modem
>> I was surprised, but integrated HDA modem consumed about 1W of power
>> even when not used. I have used the most radical solution - removed it
>> mechanically from socket. Case surface in that area become much cooler.
> 
> Most modems support the ACPI Dx states, where D3 = device powered off.
> I'd think the PCI "power no driver option" would disable the soft modem
> since it's unlikely you have a driver for it.

Modem share HDA bus/controller with sound. So PCI D3 will kill sound 
also, that is not an option. snd_hda driver itself puts all non-audio 
codecs into the HDA D3 state, but in my case it was not effective.

>> 6. HDD
>> First common recommendation is use tmpfs for temporary files. RAM is
>> cheap, fast and anyway with you.
>> Also you may try to setup automatic idle drive spin-down, but if it is
>> the only system drive you should be careful, as every spin-up reduces
>> drive's life time.
> 
> Did you increase the fsflush delay also?

I don't, but how long can it delay requests? Several minutes? Hour? Then 
there is high probability of data loss. Actually I have tried to reduce 
number of idle disk write activity, but I haven't very succeeded. Even 
in my quite simple icewm X environment something was persistently 
writing something every several minutes. I have found and disabled some 
activity sources, but it was not enough. What would happen in some 
complicated KDE/Gnome environment I am just afraid to think.

-- 
Alexander Motin