Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262839AbUKTAuU (ORCPT ); Fri, 19 Nov 2004 19:50:20 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262836AbUKTAuP (ORCPT ); Fri, 19 Nov 2004 19:50:15 -0500 Received: from gprs214-103.eurotel.cz ([160.218.214.103]:12674 "EHLO amd.ucw.cz") by vger.kernel.org with ESMTP id S262823AbUKTAcE (ORCPT ); Fri, 19 Nov 2004 19:32:04 -0500 Date: Sat, 20 Nov 2004 01:30:10 +0100 From: Pavel Machek To: hugang@soulinfo.com Cc: linux-kernel@vger.kernel.org Subject: swsusp bigdiff [was Re: [PATCH] Software Suspend split to two stage V2.] Message-ID: <20041120003010.GG1594@elf.ucw.cz> References: <20041119194007.GA1650@hugang.soulinfo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041119194007.GA1650@hugang.soulinfo.com> X-Warning: Reading this can be dangerous to your mental health. User-Agent: Mutt/1.5.6+20040722i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 63794 Lines: 2134 Hi! > This patch using pagemap for PageSet2 bitmap, It increase suspend > speed, In my PowerPC suspend only need 5 secs, cool. > > Test passed in my ppc and x86 laptop. > > ppc swsusp patch for 2.6.9 > http://honk.physik.uni-konstanz.de/~agx/linux-ppc/kernel/ > Have fun. BTW here's my curent bigdiff. It already has some rather nice swsusp speedups. Please try it on your machine; if it works for you, try to send your patches relative to this one. I hope to merge these changes during 2.6.11. Pavel --- clean/Documentation/pm.txt 2001-12-19 22:38:12.000000000 +0100 +++ linux/Documentation/pm.txt 2004-10-26 12:44:23.000000000 +0200 @@ -36,8 +36,8 @@ apmd: http://worldvisions.ca/~apenwarr/apmd/ acpid: http://acpid.sf.net/ -Driver Interface ----------------- +Driver Interface -- OBSOLETE, DO NOT USE! +----------------************************* If you are writing a new driver or maintaining an old driver, it should include power management support. Without power management support, a single driver may prevent a system with power management @@ -91,54 +91,6 @@ void pm_unregister_all(pm_callback cback); /* - * Device idle/use detection - * - * In general, drivers for all devices should call "pm_access" - * before accessing the hardware (ie. before reading or modifying - * a hardware register). Request or packet-driven drivers should - * additionally call "pm_dev_idle" when a device is not being used. - * - * Examples: - * 1) A keyboard driver would call pm_access whenever a key is pressed - * 2) A network driver would call pm_access before submitting - * a packet for transmit or receive and pm_dev_idle when its - * transfer and receive queues are empty. - * 3) A VGA driver would call pm_access before it accesses any - * of the video controller registers - * - * Ultimately, the PM policy manager uses the access and idle - * information to decide when to suspend individual devices - * or when to suspend the entire system - */ - -/* - * Description: Update device access time and wake up device, if necessary - * - * Parameters: - * dev - PM device previously returned from pm_register - * - * Details: If called from an interrupt handler pm_access updates - * access time but should never need to wake up the device - * (if device is generating interrupts, it should be awake - * already) This is important as we can not wake up - * devices from an interrupt handler. - */ -void pm_access(struct pm_dev *dev); - -/* - * Description: Identify device as currently being idle - * - * Parameters: - * dev - PM device previously returned from pm_register - * - * Details: A call to pm_dev_idle might signal to the policy manager - * to put a device to sleep. If a new device request arrives - * between the call to pm_dev_idle and the pm_callback - * callback, the driver should fail the pm_callback request. - */ -void pm_dev_idle(struct pm_dev *dev); - -/* * Power management request callback * * Parameters: @@ -262,8 +214,8 @@ ACPI Development mailing list: acpi-devel@lists.sourceforge.net -System Interface ----------------- +System Interface -- OBSOLETE, DO NOT USE! +----------------************************* If you are providing new power management support to Linux (ie. adding support for something like APM or ACPI), you should communicate with drivers through the existing generic power --- clean/Documentation/power/devices.txt 2004-11-03 01:23:03.000000000 +0100 +++ linux/Documentation/power/devices.txt 2004-11-03 02:16:40.000000000 +0100 @@ -141,3 +141,82 @@ The driver core will not call any extra functions when binding the device to the driver. +pm_message_t meaning + +pm_message_t has two fields. event ("major"), and flags. If driver +does not know event code, it aborts the request, returning error. Some +drivers may need to deal with special cases based on the actual type +of suspend operation being done at the system level. This is why +there are flags. + +Event codes are: + +ON -- no need to do anything except special cases like broken +HW. + +FREEZE -- stop DMA and interrupts, and be prepared to reinit HW from +scratch. That probably means stop accepting upstream requests, the +actual policy of what to do with them beeing specific to a given +driver. It's acceptable for a network driver to just drop packets +while a block driver is expected to block the queue so no request is +lost. (Use IDE as an example on how to do that). FREEZE requires no +power state change, and it's expected for drivers to be able to +quickly transition back to operating state. + +SUSPEND -- like FREEZE, but also put hardware into low-power state. If +there's need to distinguish several levels of sleep, additional flag +is probably best way to do that. + +All events are: + +#Prepare for suspend -- userland is still running but we are going to +#enter suspend state. This gives drivers chance to load firmware from +#disk and store it in memory, or do other activities taht require +#operating userland, ability to kmalloc GFP_KERNEL, etc... All of these +#are forbiden once the suspend dance is started.. event = ON, flags = +#PREPARE_TO_SUSPEND + +Apm standby -- prepare for APM event. Quiesce devices to make life +easier for APM BIOS. event = FREEZE, flags = APM_STANDBY + +Apm suspend -- same as APM_STANDBY, but it we should probably avoid +spinning down disks. event = FREEZE, flags = APM_SUSPEND + +System halt, reboot -- quiesce devices to make life easier for BIOS. event += FREEZE, flags = SYSTEM_HALT or SYSTEM_REBOOT + +System shutdown -- at least disks need to be spun down, or data may be +lost. Quiesce devices, just to make life easier for BIOS. event = +FREEZE, flags = SYSTEM_SHUTDOWN + +Kexec -- turn off DMAs and put hardware into some state where new +kernel can take over. event = FREEZE, flags = KEXEC + +Powerdown at end of swsusp -- very similar to SYSTEM_SHUTDOWN, except wake +may need to be enabled on some devices. This actually has at least 3 +subtypes, system can reboot, enter S4 and enter S5 at the end of +swsusp. event = FREEZE, flags = SWSUSP and one of SYSTEM_REBOOT, +SYSTEM_SHUTDOWN, SYSTEM_S4 + +Suspend to ram -- put devices into low power state. event = SUSPEND, +flags = SUSPEND_TO_RAM + +Freeze for swsusp snapshot -- stop DMA and interrupts. No need to put +devices into low power mode, but you must be able to reinitialize +device from scratch in resume method. This has two flavors, its done +once on suspending kernel, once on resuming kernel. event = FREEZE, +flags = DURING_SUSPEND or DURING_RESUME + +Device detach requested from /sys -- deinitialize device; proably same as +SYSTEM_SHUTDOWN, I do not understand this one too much. probably event += FREEZE, flags = DEV_DETACH. + +#These are not really events sent: +# +#System fully on -- device is working normally; this is probably never +#passed to suspend() method... event = ON, flags = 0 +# +#Ready after resume -- userland is now running, again. Time to free any +#memory you ate during prepare to suspend... event = ON, flags = +#READY_AFTER_RESUME +# --- clean/Documentation/power/swsusp.txt 2004-10-01 00:29:56.000000000 +0200 +++ linux/Documentation/power/swsusp.txt 2004-11-14 23:36:46.000000000 +0100 @@ -15,10 +15,21 @@ * If you change kernel command line between suspend and resume... * ...prepare for nasty fsck or worse. * - * (*) pm interface support is needed to make it safe. + * If you change your hardware while system is suspended... + * ...well, it was not good idea. + * + * (*) suspend/resume support is needed to make it safe. You need to append resume=/dev/your_swap_partition to kernel command -line. Then you suspend by echo 4 > /proc/acpi/sleep. +line. Then you suspend by + +echo shutdown > /sys/power/disk; echo disk > /sys/power/state + +. If you feel ACPI works pretty well on your system, you might try + +echo platform > /sys/power/disk; echo disk > /sys/power/state + + Article about goals and implementation of Software Suspend for Linux ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -32,42 +43,24 @@ to standby mode. Later resuming the machine the saved state is loaded back to ram and the machine can continue its work. It has two real benefits. First we save ourselves the time machine goes down and later boots up, energy costs -real high when running from batteries. The other gain is that we don't have to +are real high when running from batteries. The other gain is that we don't have to interrupt our programs so processes that are calculating something for a long time shouldn't need to be written interruptible. -Using the code - -You have two ways to use this code. The first one is is with a patched -SysVinit (my patch is against 2.76 and available at my home page). You -might call 'swsusp' or 'shutdown -z