Hi Stefan, On 9/18/06, Stefan Seyfried <[EMAIL PROTECTED]> wrote: > Hi. ... > - early writeout is faster during suspend, the gain is bigger without > compression (there is more buffered for the final sync which can take > quite some time). > - early writeout is as fast with 1% steps as it is with 20% steps. It does > not really matter in my tests (this is why i did not retry compression with > 20% steps).
Does this make sense? Theoretically forcing the writeout may cause less than optimal scheduling of the writes, no? This is the test I posted when early writeout was introduced a while ago: ---- sync every 20% 3389 pages/s 3446 pages/s 3283 pages/s sync at the end 3445 pages/s 3295 pages/s 3523 pages/s Image size ranges from 45k pages to 57k pages. The test was done on my notebook, with a XP 2500+ and 512MB of RAM. With the single sync at the end there is a delay of about 10 seconds between 'S' and '|'. ---- Listening to the HD (2.5", 4500rpm) I _hear_ it seeking when flush() is issued; If early writeout is disabled s2disk writes about 80% of the image before the kernel starts the writeout and seeking start. My guess is that if seek time is high enough early writeout will cause a seek storm and slow down s2disk. Your image is about 250MB, with early writeout at 1% it means that kernel will flush data every 2.5MB... Luca ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Suspend-devel mailing list Suspend-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/suspend-devel
