From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261676AbULTWrc (ORCPT ); Mon, 20 Dec 2004 17:47:32 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261675AbULTWrb (ORCPT ); Mon, 20 Dec 2004 17:47:31 -0500 Received: from e4.ny.us.ibm.com ([32.97.182.144]:31890 "EHLO e4.ny.us.ibm.com") by vger.kernel.org with ESMTP id S261676AbULTWgi (ORCPT ); Mon, 20 Dec 2004 17:36:38 -0500 Date: Mon, 20 Dec 2004 13:44:43 -0800 From: Nishanth Aravamudan To: Pavel Machek Cc: hugang@soulinfo.com, linux-kernel@vger.kernel.org Subject: Re: swsusp bigdiff [was Re: [PATCH] Software Suspend split to two stage V2.] Message-ID: <20041220214443.GC13972@us.ibm.com> References: <20041119194007.GA1650@hugang.soulinfo.com> <20041120003010.GG1594@elf.ucw.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041120003010.GG1594@elf.ucw.cz> X-Operating-System: Linux 2.6.10-rc3 (i686) User-Agent: Mutt/1.5.6+20040907i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Nov 20, 2004 at 01:30:10AM +0100, Pavel Machek wrote: > 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