Messages in this thread | | | Date | Fri, 26 Nov 2004 15:54:43 +0000 | From | Christoph Hellwig <> | Subject | Re: Suspend 2 merge |
| |
On Fri, Nov 26, 2004 at 01:38:48PM +0100, Pavel Machek wrote: > > Again, when you're running on limited time, twice as fast is still twice > > as fast. > > My machine suspends in 7 seconds, and that's swsusp1. According to > your numbers, suspend2 should suspend it in 1 second and LZE > compressed should be .5 second. > > I'd say "who cares". 7 seconds seems like fast enough for me. And I'm > *not* going to add 2000 lines of code for 500msec speedup during > suspend.
Yupp. Premature optimization is the roo of all evil. swsusp is
a) an absolute slowpath compared to any normal kernel operation, and called extremly seldomly b) only usefull for a small subset of all linux instances
hacking core code (fastpathes) for speedups there is a really bad idea. If you can speed it up without beeing intrusive all power to you.
> > I'm trying not to make assumptions about how we're writing the image, > > either. If you want to pipe your image over a network to some server, > > you should be able to, and not have to implement compression again in > > the writer for that. > > Suspend-over-network is obscure-enough > feature. Compressed-suspend-over-network is even worse. > > BTW my feeling is that if you want to do suspend-over-network, you > should just modify nbd to work with suspend2 and stop adding > special-purpose code to suspend.
Honestly I think it's a feature so obscure that we wouldn't ever want to merge it unless it just happens to work as a fallout of a more important feature.
- 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/
| |