From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Rafael J. Wysocki" Subject: Re: [PATCH 0/2] Kexec jump: The first step to kexec base hibernation Date: Thu, 12 Jul 2007 21:45:55 +0200 Message-ID: <200707122145.56567.rjw@sisk.pl> References: <1184167831.12556.13.camel@caritas-dev.intel.com> <200707122120.19662.rjw@sisk.pl> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-pm-bounces@lists.linux-foundation.org Errors-To: linux-pm-bounces@lists.linux-foundation.org To: david@lang.hm Cc: Jeremy Fitzhardinge , linux-kernel@vger.kernel.org, Pavel Machek , "Huang, Ying" , Andrew Morton , linux-pm@lists.linux-foundation.org, Jeremy Maitin-Shepard List-Id: linux-pm@vger.kernel.org On Thursday, 12 July 2007 21:14, david@lang.hm wrote: > On Thu, 12 Jul 2007, Rafael J. Wysocki wrote: > > >>>> note that what devices get put to sleep could be configurable, potentially > >>>> to the extreme of things like the OLPC (that have hardware designed for > >>>> cheap sleeping) going into a light suspend-to-ram state between keystrokes > >>>> if nothing else has a timer event scheduled before that. > >>>> > >>>> Suspend-do-disk (Hibernate) involves stopping the system, makeing a > >>>> snapshot of ram, writing the snapshot to somewhere and powering off the > >>>> box. on wakeup (power-on) a helper kernel boots, loads the snapshot into > >>>> ram and jumps to the kernel in the snapshot to resume operation. > >>>> > >>>> as I understand the proposal the thought is to do the following > >>>> > >>>> 1. system kernel does suspend-to-ram to put the devices into a known safe > >>>> state. > >>> > >>> Not necessarily suspend-to-RAM. I'd much prefer it if devices were not put > >>> into low power states but quiesced (ie. no DMA, no interrupts). > >> > >> as I asked in another message, is it really worth having two (or more) > >> modes here? > > > > I think so. The suspend-to-RAM mode is quite specific and on some platform > > (ie. ACPI) it requires platform support. > > > > We've already reached the conclusion that it's better to separate suspend from > > hibernation, as far as device drivers are concerned, and let's not repeat the > > discussion. > > Ok, I seem to have been miscommunicating here. the old combined > suspend/hibernate took everything to the hibernate state even if you only > needed to suspend. No, quite the other way around. For creating a hibernation image you don't have to suspend devices. Furthermore, you don't want to suspend at least some of them, because you'll be using them to save the image in a while. Also, there's no need to worry about what power state to put the device into, so that it can wake up the system from the sleep state etc. We've made hibernation use suspend-specific callbacks and that causes quite a lot of problems to appear. > I was still seeing two diffent states involved > > for suspend go to low-power mode > > for hibernate go to low-power mode, No, that is not the way to go, IMO. We can shut down devices before creating the image, but not suspend them. > kexec the new kernel, do your stuff, power off Here, instead of just powering off, we may want to make the system enter a sleep state (S4 in ACPI systems), which is similar to suspend. > note that this doesn't really matter as you have pointed out in other > messages that we don't really want to put things in low-power mode, and > Eric pointed out that kexec already handles disabling devices, so it > sounds like this may be a solved problem if he's right and an issue to be > solved differently if he's not. Shutting down devices and reinitializing them is costly. I wouldn't like to do that. Of course, in a proof-of-concept version this is viable, but IMO not in the final one. Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth