[dundee] laptop mode power saving

[Lee Hughes]

hehe.. i suppose i could, just trying to get extended battery life. tee hee..

it's seems to be working a little better now.... looks like gnome is full a fsync's

fsync's seem to wake my system up!!!

how do i get rid of them.


--- On Sun, 18/10/09, Jennifer higgins <sauntering.with.scissors at gmail.com> wrote:

From: Jennifer higgins <sauntering.with.scissors at gmail.com>
Subject: Re: [dundee] laptop mode power saving
To: "Tayside Linux User Group" <dundee at lists.lug.org.uk>
Date: Sunday, 18 October, 2009, 3:20 PM

oh just power the laptop down you big geek ;)

2009/10/18 Lee Hughes <toxicnaan at yahoo.co.uk>


hmm. well it seems that firefox writes one more file which is not to it's cache or
it's profile...it's...

lsof | grep firefox | grep tmp

firefox   27357       user   72u      REG        8,1        0  6177091 /var/tmp/etilqs_2SWFrJKOPJgPeet (deleted)


etilqs seemed to be sqlite backwards?

bizzare.... any idea's what that is or how to relocated it to my ramdisk?

Cheers,
Lee



--- On Sun, 18/10/09, Lee Hughes <toxicnaan at yahoo.co.uk> wrote:


From: Lee Hughes <toxicnaan at yahoo.co.uk>
Subject: [dundee] laptop mode power saving

To:
 "Tayside Linux User Group" <dundee at lists.lug.org.uk>
Date: Sunday, 18 October, 2009, 3:06 PM


Right,


has any got laptop mode working successfully , i'm trying to get my hard disk to spin down as long as possible, 

i've been using a combination of lm-profile, iotop -o -d 10 -b

now,  i've nailed fire fox from fsyncing all the time, that's improved things some what,

http://www.dslreports.com/forum/r23159573-Re-Make-Firefox-3x-more-responsive-with-a-simple-trick


it's also faster too boot!

however,  my hard disk sleeps for about 2mins, i've zapped syslog and klog for testing,
so there
 should be nothing on the system that should need to wake the disk for writing.

however, kkjournald is waking the disk up, (presumable to write the journal to disk)
but the file system is mounted with 

/dev/sda1 on / type ext3 (rw,relatime,errors=remount-ro,commit=600)


so, it should only commit every 10
 mins, or when we run low on memory.

  PID USER      DISK READ  DISK WRITE   SWAPIN    IO    COMMAND
  807 root           0 B/s    5.54 K/s  0.00 %  0.00 % [kjournald]
 3911 user           0 B/s    0.40 K/s  0.00 %  0.00 % gnome-power-manager



oh,actually i wonder  if it's the gnome power manager, how ironic.. looks like
the gnome power manager might be forcing a sync...

yes, it seems that a lot of gnome componets are doing a fsync, thus waking my disk

up.. :-(

all i want is, while i'm not reading new data(i.e uncached data from disk) , i want
applications to write (but delay that write until I say, or a timeout value).

i think over use of the fsync call may be
 answer, but i think there's more to it than that.

my harddrives now been dormant for 10mins....  spin down nirvarna has been reached.

looks like killing the gnome power meter has stopped the spin ups... now that's

ironic..  any replacements? or shall i go and hack it.

i wonder if this would do ssd's good too.

thoughts?

Cheers,

Lee
















      
-----Inline Attachment Follows-----

_______________________________________________
dundee GNU/Linux Users Group mailing list
dundee at lists.lug.org.uk  http://dundeelug.org.uk

https://mailman.lug.org.uk/mailman/listinfo/dundee
Chat on IRC, #tlug on irc.lug.org.uk





      
_______________________________________________

dundee GNU/Linux Users Group mailing list

dundee at lists.lug.org.uk  http://dundeelug.org.uk

https://mailman.lug.org.uk/mailman/listinfo/dundee

Chat on IRC, #tlug on irc.lug.org.uk



-----Inline Attachment Follows-----

_______________________________________________
dundee GNU/Linux Users Group mailing list
dundee at lists.lug.org.uk  http://dundeelug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/dundee
Chat on IRC, #tlug on irc.lug.org.uk


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.lug.org.uk/pipermail/dundee/attachments/20091018/549c89bf/attachment-0001.htm