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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
