suspend.c vs driver-model.txt
Quoted 9 lines
You're right, there should be an explicit call to disable I/O for the devices.
On a side, though related, note, while we were in Ottawa, several of us had a chance to sit down and hammer out exactly what needs to take place. The results exist in a notebook (a real, pencil-driven one), but have not had a chance to be expressed in ASCII text yet. (Frankly, it's a low priority right now:
-EPLATEFULL).
Is there any chance that I can transcribe the notes into ASCII for you? Or are they too arcane? Could you at least scan them?
Quoted 1 line
I assume you mean
include/linux/device.h. Yes, the enums are in the wrong
whoops, yes.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Quoted 4 lines
.../...
Quoted 8 lines
So, there needs to be a platform driver. See
include/linux/platform.handkernel/platform.cfor the start of this effort. There needs to be one of these for each platform type. They need to be registered on startup, and there needs to be prevention against multiple drivers being registered.The platform drivers need to then do whatever device transitions they need, using the
device_suspend()helpers, then put the system to sleep using their platform-speciifc method.
Good ! I've had my home-made bunch of stuff on pmac that looked just like a platform driver dealing with all sort of things (basically abtracting motherboard IOs to help drivers that need to toggle whatever reset pin or power their device up/down physically).
(See include/asm-ppc/pmac_feature.c and arch/ppc/kernel/pmac_feature.c)
On PPC, we also have that _huge_ flat ppc_md structure that contains pointers to functions like platform init, cpuinfo hooks, get/set_rtc_time, irq hooks, etc... that get filled depending on the type of machine a given kernel is booted (we support currently prep, chrp and pmac with a single kernel binary).
(see include/asm-ppc/machdep.h)
What about generalizing the platform driver to do just those things ?
I'm not too sure about how the API would look like though. For the ppc_md stuff, there is a fixed, well defined, but still arch specific set of hooks to fill.
For the pmac_feature, I use a single ppc_md. hook with variable arg list (though I do use it in a well defined format) to call a list of "feature" functions that is usually exetended on every new kind of motherboard I add support for. Not every machine support all functions, etc... it would probably be a pain to define this as a flat list of function pointers.
Anybody has better ideas on how to deal with those platform specific things while still making them fit in a platform driver (their logical place, especially if the platform driver ends up in driverfs, a nice way to expose some motherboard specific settings/tweaks to userland ?
Quoted 7 lines
The ACPI code that is in there is relatively close. I did that on purpose, thinking that this stuff will be generalized someday. However, whatever end solution that exists _must_ not be designed the behavior of ACPI. In fact, I am hesitant talking about this general model on this list for fear that someone that is already brainwashed by the Great Firmware Abomination will say either "We can already do this!" or "I'll do it (in ACPI first and generalize it)."
I don't know ACPI well enough to talk, but the mecanism I use on PPC is pretty basic today. The sleep procedure is dealt with by the driver of the Power Management chip when it gets a sleep request from userland, but that can (should be) moved to the platform driver.
Then, it does my own version of looping all devices sending them suspend events etc... (did we ever write down what we defined during OLS for those events semantics ?)
Then, calls the platform driver to deal with lower level motherboard stuffs that haven't be done by any drivers and need to be done last
Finally it deals with the CPU (flushing caches, etc...).
I omitted intentionally the fact that it has to send a special command to the power manager chip just before the low level mother board stuff, that will cause that chip to shut the CPU down the next time it goes to SLEEP state, which we do in the last step.
So most of this scenario is arch/platform specific cuisine. That is, all but the first step has to be self contained somewhere in the platform driver, those are arch/platform/cpu specific, nothing good we can do about them.
This end up breaking the scenario into 2 main phases
1) Looping around all drivers doing the suspend dance (suspend request,save_state & suspend, ...) as we discussed. This is mostly (completely ?) platform independant (except for the exact state a given device has to be put to, oh well, let's deal that inside the device driver for now)
2) Doing whatever additional arch specific code is needed to snooze
the machine.
1) is generic. 2) is arch/platform code.
The nice thing here, I beleive, is that suspend to disk could then just be an additional generic step between 1) and 2) that takes care of dumping memory content to disk.
As far as suspend to disk is concerned, we have all sort of nasty issues we discussed that I don't feel like resuming right now, so I would rather have the lowest level driver able to play the backing store export a couple of "hooks" used to dump the pages to the medium, those would work synchronously, without VM activity, etc... The driver that is target for that would have pre-allocated what it needs, pre-mapped DMA mappings it needs etc...
Though, thinking as I write, injecting requests via the BIO layer may be a nicer solution, provided we make sure the driver won't get any request _but_ the ones we feed it. I don't trust a mecanism that would selectively stop given kernel threads, then just hope nobody will push requests any more. That's way too fragile to my taste. I'd rather freeze the request queue for real like any other device, then eventually provide a special pass-through.
Quoted 8 lines
<harshness>
The ACPI subsystem has a tendency to duplicate existing interfaces, or come up with completely new ones, intending to be applicable to the rest of the kernel. The are highly ACPI-centric, yet they expect them to be standard. They aren't publicized or discussed on any list but this one. But, they're left to be fixed up and cleaned up by the other people in the community.
Quoted 6 lines
I refuse to lay blame on anyone for my inability to work faster or harder. But, a lot of people complain that I've been working on this for a year, and they still can't suspend their laptop. My rebuttal is that if I had actually gotten cooperation and compromise at the source level, in many areas, we probably wouldn't still be dealing with this. </harshness>
I'm probably to blame for not writing code here as I mostly only contributed with speetch and ideas (and my old pmac code) so far. I'm sorry, i'm not even been able to find time to convert the pmac drivers to driverfs yet :( My time dedicated to linux is spare, and so variable, and it tends to be quite small nowadays.
Quoted 3 lines
So, someone needs to do it. I don't have time. And, I don't trust anyone related to ACPI to do it right (except maybe Andy in a different context, but he's overworked as it is).
I've subscribed to this list, it may be a good oportunity to use it for discussing & defining things at the API level now.
Regards,
Ben.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Quoted 6 lines
On a side, though related, note, while we were in Ottawa, several of us had a chance to sit down and hammer out exactly what needs to take place. The results exist in a notebook (a real, pencil-driven one), but have not had a chance to be expressed in ASCII text yet. (Frankly, it's a low priority right now:
-EPLATEFULL).
Did you talk at all about the fact that pci.h has its own set of power-management hooks that almost-but-not-quite map to the ACPI ones, and how to resolve that?
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Quoted 4 lines · Lyle
Quoted 4 lines
You're right, there should be an explicit call to disable I/O for the devices.
Quoted 8 lines
Quoted 5 lines
On a side, though related, note, while we were in Ottawa, several of us had a chance to sit down and hammer out exactly what needs to take place. The results exist in a notebook (a real, pencil-driven one), but have not had a chance to be expressed in ASCII text yet. (Frankly, it's a low priority right now:
-EPLATEFULL).Is there any chance that I can transcribe the notes into ASCII for you? Or are they too arcane? Could you at least scan them?
I don't do the scanning thing. :)
I would love to pass it off on someone, but there's a lot of context involved.
Basically, what we need is for someone to develop a general power management model for the kernel. The path to implementation is partially complete, but someone needs to fill in the blanks, and make sure that other platforms are accounted for.
The mechanism for transition should be a driverfs file which a user or app can write to. There could also be a hook into the sys_reboot() call.
The handler for this is generic. There will likely be generic power management transitions, like swsusp. But, there will always be platform-specific transitions, and platform-specific operations for even the generic transitions. So, the generic handler needs to pass the command to the "platform driver".
So, there needs to be a platform driver. See include/linux/platform.h and kernel/platform.c for the start of this effort. There needs to be one of these for each platform type. They need to be registered on startup, and there needs to be prevention against multiple drivers being registered.
The platform drivers need to then do whatever device transitions they need, using the device_suspend() helpers, then put the system to sleep using their platform-speciifc method.
The ACPI code that is in there is relatively close. I did that on purpose, thinking that this stuff will be generalized someday. However, whatever end solution that exists _must_ not be designed the behavior of ACPI. In fact, I am hesitant talking about this general model on this list for fear that someone that is already brainwashed by the Great Firmware Abomination will say either "We can already do this!" or "I'll do it (in ACPI first and generalize it)."
<harshness>
The ACPI subsystem has a tendency to duplicate existing interfaces, or come up with completely new ones, intending to be applicable to the rest of the kernel. The are highly ACPI-centric, yet they expect them to be standard. They aren't publicized or discussed on any list but this one. But, they're left to be fixed up and cleaned up by the other people in the community.
I refuse to lay blame on anyone for my inability to work faster or harder. But, a lot of people complain that I've been working on this for a year, and they still can't suspend their laptop. My rebuttal is that if I had actually gotten cooperation and compromise at the source level, in many areas, we probably wouldn't still be dealing with this. </harshness>
So, someone needs to do it. I don't have time. And, I don't trust anyone related to ACPI to do it right (except maybe Andy in a different context, but he's overworked as it is).
-pat
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Hi!
Quoted 3 lines
The nice thing here, I beleive, is that suspend to disk could then just be an additional generic step between 1) and 2) that takes care of dumping memory content to disk.
It can not, because after saving state you can not easily write to swap partition.
Quoted 7 lines
As far as suspend to disk is concerned, we have all sort of nasty issues we discussed that I don't feel like resuming right now, so I would rather have the lowest level driver able to play the backing store export a couple of "hooks" used to dump the pages to the medium, those would work synchronously, without VM activity, etc... The driver that is target for that would have pre-allocated what it needs, pre-mapped DMA mappings it needs etc...
Too complicated. Look at swsusp -- it is designed not to need pre-allocated pages, pre-mapped DMA etc.
Quoted 6 lines
Though, thinking as I write, injecting requests via the BIO layer may be a nicer solution, provided we make sure the driver won't get any request _but_ the ones we feed it. I don't trust a mecanism that would selectively stop given kernel threads, then just hope nobody will push requests any more. That's way too fragile to my taste. I'd rather freeze
Why is it fragile? You just have to be carefull. If you mark thread as PF_IOTHREAD it must *not* generate requests unless told to.
Pavel
Signature · 8 lines
Worst form of spam? Adding advertisment signatures ala sourceforge.net. What goes next? Inserting advertisment *into* email? ------------------------------------------------------- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31
Quoted 8 lines
Hi!
Quoted 3 lines
The nice thing here, I beleive, is that suspend to disk could then just be an additional generic step between 1) and 2) that takes care of dumping memory content to disk.
It can not, because after saving state you can not easily write to swap partition.
Well, you have to. I mean, you can't write to swap before saving state (or you'll miss some state information). Which means the device dealing with the save has to be treated as a special case. At least, that's what we figured out when discussing this during OLS.
Quoted 10 lines
Quoted 7 lines
As far as suspend to disk is concerned, we have all sort of nasty issues we discussed that I don't feel like resuming right now, so I would rather have the lowest level driver able to play the backing store export a couple of "hooks" used to dump the pages to the medium, those would work synchronously, without VM activity, etc... The driver that is target for that would have pre-allocated what it needs, pre-mapped DMA mappings it needs etc...
Too complicated. Look at swsusp -- it is designed not to need pre-allocated pages, pre-mapped DMA etc.
I didn't look at it recently, but does it work properly in a solid way whatever state other devices are ?
Quoted 9 lines
Quoted 6 lines
Though, thinking as I write, injecting requests via the BIO layer may be a nicer solution, provided we make sure the driver won't get any request _but_ the ones we feed it. I don't trust a mecanism that would selectively stop given kernel threads, then just hope nobody will push requests any more. That's way too fragile to my taste. I'd rather freeze
Why is it fragile? You just have to be carefull. If you mark thread as
PF_IOTHREADit must *not* generate requests unless told to.
I still don't like that very much, but that could still be a solution. Anyway, I need to look at your latest swsusp work.
Ben.
-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31
Quoted 1 line
Discussing with who?
We had a Power Management BOF there, among others, Patrick Mochel, Greg KH, Andy, Paulus, Jeff Garzik, ...
Quoted 3 lines
Its rather simple: free half of memory, stop everything, save device state, copy used memory into free memory, continue devices, save data from "free" memory into swap.
Ok, so you first push as much as you can to swap to free half of memory. Then, when you say you copy used memory, I assume you copy all of RAM including kernel memory (kernel data structures etc...) right ?
What do you mean by "stop everything" ? Stop user processes ? Kernel threads ? both ? Then, you only save device state (and then suspend devices) after you have "stopped everything" ?
Ben.
-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31
Hi!
Quoted 11 lines
Quoted 6 lines
Quoted 3 lines
The nice thing here, I beleive, is that suspend to disk could then just be an additional generic step between 1) and 2) that takes care of dumping memory content to disk.
It can not, because after saving state you can not easily write to swap partition.
Well, you have to. I mean, you can't write to swap before saving state (or you'll miss some state information). Which means the device dealing with the save has to be treated as a special case. At least, that's what we figured out when discussing this during OLS.
Discussing with who?
Its rather simple: free half of memory, stop everything, save device state, copy used memory into free memory, continue devices, save data from "free" memory into swap.
Quoted 5 lines
Quoted 2 lines
Too complicated. Look at swsusp -- it is designed not to need pre-allocated pages, pre-mapped DMA etc.
I didn't look at it recently, but does it work properly in a solid way whatever state other devices are ?
It is designed to be safe, yes.
Pavel
Signature · 8 lines
Worst form of spam? Adding advertisment signatures ala sourceforge.net. What goes next? Inserting advertisment *into* email? ------------------------------------------------------- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31
Quoted 4 lines
(Most comments were added 5 minutes ago).
Does it look understendable now?
Yes, definitely more clear, there are probably interesting bits in there to re-use for suspend-to-ram as well.
However, the mucking with kernel threads is definitely specific to your need of keeping the target block device up without getting nasty filesystem-originated requests.
Actually, I'm considering we could probably do both :) That is suspend-to-disk is actually a superset of suspend-to-RAM. So we could suspend-to-RAM-and-disk, basically allowing us to wakeup fast from RAM, but still be able to wakeup from disk if battery is exhausted.
Anyway, in your scheme, the main thing I'm currently concerned about is the free_some_memory/do_suspend_sync/driver_suspend thing which is nasty. How do you deal with memory beeing re-allocated after free_some_memory ? (typically driver needing RAM for saving state or a non-filesystem-related daemon doing a kmalloc (or a driver from a tasklet). Also, do you push as much as possible to swap ? Or may such an allocation still cause more swap activity ? This can be nasty especially since swap here can be an mmap'd file, or a swap file, thus possibly racing with the fact you stopped filesystem specific daemons.
Then, finally, the drivers_suspend() state must be broken in pieces, that is needed for both suspend-to-RAM and -to-disk, (see my other email).
Ben.
-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31
Hi!
Quoted 4 lines
Quoted 1 line
Discussing with who?
We had a Power Management BOF there, among others, Patrick Mochel, Greg KH, Andy, Paulus, Jeff Garzik, ...
Oops... I guess I should have been there :-(. Sorry.
Quoted 8 lines
Quoted 3 lines
Its rather simple: free half of memory, stop everything, save device state, copy used memory into free memory, continue devices, save data from "free" memory into swap.
Ok, so you first push as much as you can to swap to free half of memory. Then, when you say you copy used memory, I assume you copy all of RAM including kernel memory (kernel data structures etc...) right ?
Yes.
Quoted 2 lines
What do you mean by "stop everything" ? Stop user processes ? Kernel threads ? both ?
Stop all user processes and all kernel processes that could cause trouble. Don't stop kapm-idled (for example) but be sure to stop ext3-commitd (or how is that beast called).
Quoted 2 lines
Then, you only save device state (and then suspend devices) after you have "stopped everything" ?
Yes.
Code looks like this:
void do_software_suspend(void)
{
arch_prepare_suspend();
if (prepare_suspend_console())
printk( "%sCan't allocate a console... proceeding\n", name_suspend);
if (!prepare_suspend_processes()) {
/* At this point, all user processes and "dangerous"
kernel threads are stopped. Free some memory, as we
need half of memory free. */
free_some_memory();
/* No need to invalidate any vfsmnt list -- they will be valid after resume, anyway.
*
* We sync here -- so you have consistent filesystem state when things go wrong.
* -- so that noone writes to disk after we do atomic copy of data.
*/
PRINTK("Syncing disks before copy\n");
do_suspend_sync();
/* Save state of all device drivers, and stop them. */
if(drivers_suspend()==0)
/* If stopping device drivers worked, we proceed basically into
* suspend_save_image.
*
* do_magic(0) returns after system is resumed.
*
* do_magic() copies all "used" memory to "free" memory, then
* unsuspends all device drivers, and writes memory to disk
* using normal kernel mechanism.
*/
do_magic(0);
PRINTK("Restarting processes...\n");
thaw_processes();
}
software_suspend_enabled = 1;
MDELAY(1000);
restore_console ();
}(Most comments were added 5 minutes ago).
Does it look understendable now?
Pavel
Signature · 8 lines
Worst form of spam? Adding advertisment signatures ala sourceforge.net. What goes next? Inserting advertisment *into* email? ------------------------------------------------------- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31
Hi!
Quoted 9 lines
Quoted 3 lines
(Most comments were added 5 minutes ago).
Does it look understendable now?
Yes, definitely more clear, there are probably interesting bits in there to re-use for suspend-to-ram as well.
However, the mucking with kernel threads is definitely specific to your need of keeping the target block device up without getting nasty filesystem-originated requests.
Stopping processes is needed (and being used) by suspend-to-ram, because anything else is too hard for the drivers (I believe).
Quoted 5 lines
Actually, I'm considering we could probably do both :) That is suspend-to-disk is actually a superset of suspend-to-RAM. So we could suspend-to-RAM-and-disk, basically allowing us to wakeup fast from RAM, but still be able to wakeup from disk if battery is exhausted.
Good idea. Thinkpads could do that, it was called RediSafe or something like that. Disadvantage is that suspend then takes quite long time.
Quoted 6 lines
Anyway, in your scheme, the main thing I'm currently concerned about is the free_some_memory/do_suspend_sync/driver_suspend thing which is nasty. How do you deal with memory beeing re-allocated after
free_some_memory? (typically driver needing RAM for saving state or a non-filesystem-related daemon doing a kmalloc (or a driver from a tasklet).
I free as much memory as possible. So, if driver allocation fails, it would fail on running system, too. If there was anything that could be swapped out, I'd already swapped it out.
Quoted 2 lines
Also, do you push
as much as possible to swap ?
Yes.
Quoted 2 lines
Or may such an allocation still
cause more swap activity ?
No.
Quoted 3 lines
This can be nasty especially since
swap here can be an mmap'd file, or a swap file, thus possibly racing with the fact you stopped filesystem specific daemons.
swsusp actually suspends right into swap *partition*. So I indeed need swap partition and not swap file.
Quoted 3 lines
Then, finally, the
drivers_suspend()state must be broken in pieces, that is needed for both suspend-to-RAM and -to-disk, (see my other email).
Well, if you are willing to live with ugly-but-harmless spindown-then-spinup and blank-then-unblank, its actually possible to keep current system.
Pavel
Signature · 8 lines
Worst form of spam? Adding advertisment signatures ala sourceforge.net. What goes next? Inserting advertisment *into* email? ------------------------------------------------------- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31
Sorry about the delay in responding...
Quoted 30 lines
Quoted 3 lines
The platform drivers need to then do whatever device transitions they need, using the
device_suspend()helpers, then put the system to sleep using their platform-speciifc method.Good ! I've had my home-made bunch of stuff on pmac that looked just like a platform driver dealing with all sort of things (basically abtracting motherboard IOs to help drivers that need to toggle whatever reset pin or power their device up/down physically).
(Seeinclude/asm-ppc/pmac_feature.candarch/ppc/kernel/pmac_feature.c)On PPC, we also have that _huge_ flat
ppc_mdstructure that contains pointers to functions like platform init, cpuinfo hooks, get/set_rtc_time, irq hooks, etc... that get filled depending on the type of machine a given kernel is booted (we support currently prep, chrp and pmac with a single kernel binary).
(seeinclude/asm-ppc/machdep.h)What about generalizing the platform driver to do just those things ?
I'm not too sure about how the API would look like though. For the
ppc_mdstuff, there is a fixed, well defined, but still arch specific set of hooks to fill.For the
pmac_feature, I use a singleppc_md. hook with variable arg list (though I do use it in a well defined format) to call a list of "feature" functions that is usually exetended on every new kind of motherboard I add support for. Not every machine support all functions, etc... it would probably be a pain to define this as a flat list of function pointers.
Quoted 4 lines
Anybody has better ideas on how to deal with those platform specific things while still making them fit in a platform driver (their logical place, especially if the platform driver ends up in driverfs, a nice way to expose some motherboard specific settings/tweaks to userland ?
That's what the platform_notify() function pointer is for - to have the platform/firmware driver set device-specific information when it's registered. How you want to implement is up to you, and unfortunately there are no examples (yet).
When you do get the call, you can simply create driverfs files with common handlers for the platform-specific attributes. How you map the device pointer that you get to the data is left as an exercise to the reader. ;)
Quoted 8 lines
I don't know ACPI well enough to talk, but the mecanism I use on PPC is pretty basic today. The sleep procedure is dealt with by the driver of the Power Management chip when it gets a sleep request from userland, but that can (should be) moved to the platform driver.
Then, it does my own version of looping all devices sending them suspend events etc... (did we ever write down what we defined during OLS for those events semantics ?)
Yes. I'll try and get to them this week. (Operative word: try).
Quoted 11 lines
This end up breaking the scenario into 2 main phases
1) Looping around all drivers doing the suspend dance (suspend request,
save_state& suspend, ...) as we discussed. This is mostly (completely ?) platform independant (except for the exact state a given device has to be put to, oh well, let's deal that inside the device driver for now)2) Doing whatever additional arch specific code is needed to snooze
the machine.1) is generic. 2) is
arch/platformcode.
Yes, that's basically what we discussed, and the right way to go. We have helper functions that walk the device list, doing what ever platform-speciifc stuff in the meantime. (Similar to how ACPI does it today).
There are just other details, like actually getting it right, and having the transition functions get called from a common place. And, making sure it looks the same to userspace.
Quoted 6 lines
As far as suspend to disk is concerned, we have all sort of nasty issues we discussed that I don't feel like resuming right now, so I would rather have the lowest level driver able to play the backing store export a couple of "hooks" used to dump the pages to the medium, those would work synchronously, without VM activity, etc... The driver that is target for that would have pre-allocated what it needs, pre-mapped DMA mappings it
Quoted 8 lines
needs etc...
Though, thinking as I write, injecting requests via the BIO layer may be a nicer solution, provided we make sure the driver won't get any request _but_ the ones we feed it. I don't trust a mecanism that would selectively stop given kernel threads, then just hope nobody will push requests any more. That's way too fragile to my taste. I'd rather freeze the request queue for real like any other device, then eventually provide a special pass-through.
I'm not going to comment, because I don't know the stuff well enough.
Quoted 5 lines
I'm probably to blame for not writing code here as I mostly only contributed with speetch and ideas (and my old pmac code) so far. I'm sorry, i'm not even been able to find time to convert the pmac drivers to driverfs yet :( My time dedicated to linux is spare, and so variable, and it tends to be quite small nowadays.
No need to apologize. I cc'ed you because you've always been incredibly helpful in keeping me honest. As much as I think you should quit your job and dedicate your life to getting Linux power management right, I realize that I'm being a bit unrealistic, and I have to life with the intermittent code.
-pat
-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31
Quoted 2 lines
Stopping processes is needed (and being used) by suspend-to-ram, because anything else is too hard for the drivers (I believe).
I don't agree, and I have this working fairly well on pmac's today, though that is a limited set of drivers used on these laptops I had to fix.
Quoted 9 lines
Quoted 5 lines
Actually, I'm considering we could probably do both :) That is suspend-to-disk is actually a superset of suspend-to-RAM. So we could suspend-to-RAM-and-disk, basically allowing us to wakeup fast from RAM, but still be able to wakeup from disk if battery is exhausted.
Good idea. Thinkpads could do that, it was called RediSafe or something like that. Disadvantage is that suspend then takes quite long time.
Well, if done to a swap partition, with the average throughput of recent U/DMA disks on things like my laptop, that is about 14Mb/sec, suspending would indeed take about 20 seconds, which is long, but still realistic.
Quoted 28 lines
Quoted 6 lines
Anyway, in your scheme, the main thing I'm currently concerned about is the free_some_memory/do_suspend_sync/driver_suspend thing which is nasty. How do you deal with memory beeing re-allocated after
free_some_memory? (typically driver needing RAM for saving state or a non-filesystem-related daemon doing a kmalloc (or a driver from a tasklet).I free as much memory as possible. So, if driver allocation fails, it would fail on running system, too. If there was anything that could be swapped out, I'd already swapped it out.
Quoted 2 lines
Also, do you push
as much as possible to swap ?Yes.
Quoted 2 lines
Or may such an allocation still
cause more swap activity ?No.
Quoted 3 lines
This can be nasty especially since
swap here can be an mmap'd file, or a swap file, thus possibly racing with the fact you stopped filesystem specific daemons.swsusp actually suspends right into swap *partition*. So I indeed need swap partition and not swap file.
Quoted 7 lines
Quoted 3 lines
Then, finally, the
drivers_suspend()state must be broken in pieces, that is needed for both suspend-to-RAM and -to-disk, (see my other email).Well, if you are willing to live with ugly-but-harmless spindown-then-spinup and blank-then-unblank, its actually possible to keep current system.
Well... why not improve things then ? We are trying to get the proper semantics of the various suspend steps thrown at drivers and then drivers fixed, I'd rather see swsusp make use of this as well :)
Ben.
-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31