Re: Fighting for the power.

On 2009-May-04 06:19:36 +0300, Alexander Motin <mav_at_freebsd.org> wrote:
>System will always have tons of waiting callouts and timeouts to be 
>handled. So timer will be always needed. Working timer.

Yes, but a tickless kernel will let the CPU stay asleep for longer
since it doesn't need to wake up just to discover there's nothing
to do.

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

I've recently (in the last few days) worked through minimising the
write activity on the SSD in my laptop (I wrote a tool that monitors
write transfers via devstat(3) and it would be possible to track down
the actual modified files via kqueue(2) if necessary).  I'm now down
to about two chunks of about 13 transfers each per hour (due to entopy
saving and ntp.drift updating).  The changes I made were:
1) Mount the SSD filesystems as noatime
2) Turn off all local syslogging (syslog is directed to another
   system when my laptop is at home, lost otherwise).
3) Change maillog rotation to size instead of daily
4) Run save-entropy once per hour instead of every 11 minutes.
5) Patch the save-entropy script to reduce the write load when
   it's run (see PR bin/134225).
6) Use a swap-back /tmp

By default, ntpd updates ntp.drift every hour.  I might do some
monitoring and see if the drift changes significantly over time.  If
it doesn't, hard-wiring the ntp.drift file will save some writes.
(The other option would be to tweak the relevant timecounter until the
actual drift is 0 and then stop ntpd and just run something like
ntpdate regularly to compensate for the remaining drift).

Experimentation shows that firefox3 generates a fairly heavy write
load - continuously updating several internal databases whilst it
is in use.  Turning off the "Block reported attack sites" and
"Block reported web forgeries" options under 'Security' stops it
updating urlclassifier3.sqlite.

Note that when you update a file, you implicitly update the associated
inode and the filesystem superbock.

> What would happen in some 
>complicated KDE/Gnome environment I am just afraid to think.

I'd recommend avoiding a heavyweight window manager and using
something like fwvm or vtwm.

-- 
Peter Jeremy