Message-Id: <1171232786.4493.62.camel@nigel.suspend2.net>
Date:	Mon, 12 Feb 2007 09:26:26 +1100
From:	Nigel Cunningham <nigel@...el.suspend2.net>
To:	Willy Tarreau <w@....eu>
Cc:	Robert Hancock <hancockr@...w.ca>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: NAK new drivers without proper power management?

Hi.

On Sun, 2007-02-11 at 22:52 +0100, Willy Tarreau wrote:
> On Sun, Feb 11, 2007 at 12:31:14PM -0600, Robert Hancock wrote:
> > Willy Tarreau wrote:
> > >Nigel, don't take it as a personal offense, but I think it is a very
> > >centric view of Linux usages. Where I work, Linux is used a lot on
> > >servers and appliances. It is used for mail relays, HTTP proxies,
> > >anti-viruses, firewalls, routers, load balancers, UTM, SSH relays,
> > >etc... Nobody would ever want to enable power management on those
> > >machines, let alone suspend which would cause a major havoc, would
> > >the system decide to enter suspend for any reason.
> > >
> > >Many people also have Linux on their notebooks, but as a dual-boot. You
> > >read the word ? "dual-boot". It means that they cleanly shutdown their
> > >system every time they don't use it anymore, and they won't know what
> > >OS they'll use next time.
> > >
> > >I've never heard anyone there complaining "oh, I'm fed up with this
> > >boring boot, I always have to wait 30 seconds when I need to do
> > >something, I wish I could suspend and resume". It is considered the
> > >normal way of using their PCs.
> > 
> > I think your experience is rather different than that of Joe Average 
> > User who doesn't frequent kernel lists, and also I think you'll find 
> > that for a lot of Linux laptop users that don't use supend, the reason 
> > is that it doesn't work reliably, quite often due to driver issues.
> 
> I would believe it if I knew people using suspend/resume on the other OS.
> But that's not the case either. Also, it happens that with today's RAM
> sizes, suspend-to-disk then resume can be several times slower than a
> clean fresh boot. When you have 1 GB to write at 20 MB/s, it takes 50
> seconds to shut down, and as much to restart. Compare this to 5-10
> seconds for a shutdown and 30-50 seconds for a cold boot, and it might
> give you another clue why there are people not interested in such a
> feature.

I'm using M$ hibernation and Suspend2 to dual boot on our desktop (dtv
card that Linux doesn't support well yet), and I know other Suspend2
users doing the same. It's made earier by the fact that Suspend2 lets
you reboot instead of powering down.

As to comparing the speed with the time to boot, your estimates are way
out. Both will of course vary with the harddrive and cpu speeds and
compression qualities of the image, but with Suspend2, I'm seeing speeds
more in the range of 40-100MB/s, and even had a resport of 160MB/s a
couple of days ago. The rule of thumb I use is:

Run hdparm -t (or equiv) on the drive you'll be using:

nigel@...el:~$ sudo hdparm -t /dev/hda

/dev/hda:
 Timing buffered disk reads:  120 MB in  3.02 seconds =  39.70 MB/sec

Then calculate RAM_IN_MB / 2 / HDPARM_RESULT = seconds to read/write
image.

In my case: 1024 / 2 / 39.7 = approx 12 seconds. The / 2 is because with
LZF compression, you normally get about 50% compression.

I think the mean reason some people aren't interested in suspend to disk
is because of myths (if you'll excuse the term) like the one you've put
above. Of course that values you give were more accurate for swsusp and
uswsusp until recently, but Suspend2 has had async I/O and compression
for years, so all I can really do is encourage you to try again.

Of course there's another factor you're not taking into account: With
suspending to disk, you don't have to close and reopen documents or shut
down and restart applications. The time to do that should be factored
into the non-suspend-to-disk time to compare apples with apples.

Regards,

Nigel

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists