Date: Mon, 6 Feb 2006 13:52:53 +0100
From: Pavel Machek <pavel@suse.cz>
To: Jens Axboe <axboe@suse.de>
Cc: Nigel Cunningham <nigel@suspend2.net>, Rafael Wysocki <rjw@sisk.pl>,
       linux-kernel@vger.kernel.org,
       Suspend2 Devel List <suspend2-devel@lists.suspend2.net>
Subject: Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)
Message-ID: <20060206125253.GJ4101@elf.ucw.cz>
References: <20060201113710.6320.68289.stgit@localhost.localdomain> <200602061402.54486.nigel@suspend2.net> <20060206105954.GD3967@elf.ucw.cz> <200602062213.24735.nigel@suspend2.net> <20060206124034.GH4101@elf.ucw.cz> <20060206125035.GT13598@suse.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20060206125035.GT13598@suse.de>
User-Agent: Mutt/1.5.9i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2621
Lines: 57

Hi!

> > > > interface for userland, and BTW going async will not give you too much
> > > > of performance advantage here...
> > > 
> > > How do you know that? Suspend2 has async I/O, and can write the image as 
> > > fast as the drive can take it. Some testing I did a while ago showed a max 
> > > throughput of 16MB/s for swsusp vs 35 (what the drive is capable of) for 
> > > Suspend2. Add LZF compression and it's 70MB/s vs 16MB/s.
> > 
> > Userspace is perfectly capable of saturating I/O subsystem. No magical
> > "async io" is needed for that. time dd if=/dev/zero of=/dev/hda
> > bs=... if you don't believe me.
> 
> But the in-kernel swsusp stuff (looking at the current linus kernel now)
> does write each page to the swap in a sync manner. That definitely is
> pretty slow, I would not be surprised if Nigels numbers are correct. If
> you repeated without write back caching enabled, a factor 10 in slowdown
> as compared to async io would not surprise me.
> 
> Why don't you split the writeout into a few seperate loops? Step 1,
> submission, step 2, wait for completion, step 3, check for io errors.
> You could even collapse step 2+3 if you wanted, the important bit is to
> queue all the io first.

Nigel is right for current in-kernel stuff, but even existing userland
suspend code at suspend.sf.net should solve this particular problem.

> > > > Current uswsusp is 3K lines of code in kernel, 1K lines of code in
> > > > userspace.
> > > >
> > > > When we are done, we'll have perhaps 2.5K lines of code in kernel
> > > > (in-kernel swap writing support goes away), and maybe 20K lines in
> > > > userspace.
> > > 
> > > Without adding which out of async I/O, compression, encryption, swap file 
> > > support, and ordinary file support?
> > 
> > I'll get same bandwidth as you, without need for async I/O. Async I/O
> > is not really a feature, suspend speed is. (There are existing
> > interfaces for doing AIO from userspace, anyway, but I'm pretty sure
> > they will not be needed
> 
> If you keep writing single pages sync, you sure as hell wont get
> anywhere near async io in speed...

well, we can perfectly do 128K block... just read 128K into userspace
buffer, flush it via single write to block device. That should get us
very close enough to media speed.
								Pavel
-- 
Web maintainer for suspend.sf.net (www.sf.net/projects/suspend) wanted...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/