On Tue, Sep 19, 2006 at 02:28:36AM +0200, Luca Tettamanti wrote: > 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?
In my case, it looks like it makes sense. Without early writeout, it takes some seconds to write a part of the image (~50% ?) before the disk starts flushing. Then writing stalls and waits on the disk, then it completes. The final sync takes about 5 seconds. With early writeout, it starts writing much sooner (1 sec? 20%) and the final sync takes another 1-2 seconds. In the end, it is about 4-5 seconds faster. > 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 '|'. > ---- These variations look like they are more likely caused by the "image is smaller so more memory for buffering" effect i observed than actual differences because of the additional flushing, but i might be wrong. > 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 Which brings up the question why we have to seek at all and cannot write the image one block after the other onto the disk... > 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... Yes, but i think write requests in sizes >1MB should be pretty ok performance wise. -- Stefan Seyfried \ "I didn't want to write for pay. I QA / R&D Team Mobile Devices \ wanted to be paid for what I write." SUSE LINUX Products GmbH, Nürnberg \ -- Leonard Cohen ------------------------------------------------------------------------- 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
