On Tuesday, 19 September 2006 04:32, Stefan Seyfried wrote:
> 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.
In fact I'd think in sizes comparable with the drive's cache size.
Rafael
--
You never change things by fighting the existing reality.
R. Buckminster Fuller
-------------------------------------------------------------------------
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
