Messages in this thread | | | Date | Mon, 10 Mar 2003 20:23:00 +0100 | From | Pavel Machek <> | Subject | Re: SWSUSP Discontiguous pagedir patch |
| |
Hi!
> > But your solution would also only support *one* suspend partition, > > right? (And patches for using more than one swap partition are > > available for 2.4.X; I don't like them due to added complexity). > > Having a dedicated partition has an advantage in just that - it's > dedicated to saving system state. Users must consciously create it, and > must make it as big as the size of memory they have (or will have). Plus, > it's not tied to the amount of memory being used when you suspend.
That's a problem. Users do not have suspend partitions, but they do have swap partition. And repartitioning existing installation is very painfull. OTOH it is true that if we want "emergency-suspend-to-disk-when-battery-low", dedicated partition makes some sense.... ... Well. You can always do swapoff, swapon, swsusp. Maybe some processes will die, but that's life ;-).
[But for that you'd have to guarantee that suspend always works, which is hard, anyway.]
> Swap space has a specific purpose, I see it as a detriment to overload its > intended usage. Of couse, that's just my opinion, and I don't have code to > back it up.
Well, I see it as advantage because I have swap space anyway (rarely really used), so why not reuse it for swsusp?
> > It is pretty magical operation, so you are at least warned. [And this has > > nothing to do with fact we suspend-to-swap]. > > IMO, warnings should be conveyed in comments, not in cryptic function > names. Besides, there is nothing magical about it, unless that sequence of > instructions actually does make your computer glow, levitate, or turn into > a mermaid. In which case, I would like to know where I can find one. ;)
:-). Well, comments were getting out of date because code was in permanent flux. It makes sense to comment it now.
> > Your solution will not work if your suspend partition is not there. > > I didn't mean to sound like a hypocrit, I apologize. The advantage of > using a dedicated partition over swap is that in order to create the > partition, the user must make a conscious decision to do so. > > There are parameters that can be enforced when making the partition, like > the size and its existence on a persistant medium. These can be enforced > by a user making a swap partition, but it places extra burden on the user.
Well, IMO checklist like:
if you want to use swsusp you have to
a) check swap is on persistent medium
b) make sure swap is at least as big as memory/2 [not really neccessary, we might be lucky and swsusp with 30MB of swap...]
is easier for the user than repartitioning their harddrives. [I'd like to see someone running swap on floppy ;-)]
> > So you don't really want to create separate "suspend partition"? Good. > > Sorry, the patch included a few distinct things, and I should have made it > a bit more clear. In includes: > > - A generic PM framework which PM drivers can register with. > > Users can specificy which handler they wish to use for different states, > based on their preference or the capabilities of their systems. > > They can also use one mechanism for entering power states: > /sys/power/power_state, instead of relying different mechanisms for > different PM drivers (/proc/acpi/sleep vs. apm(1) > vs. sys_reboot()).
I believe sys_reboot() is the right way to do that. /sys/power/... needs sysfs mounted etc. /proc/acpi/sleep just happened to already be there and be very convenient.
> In the long run, I'd like to develop a solution using a dedicated > partition. But, that wouldn't necessarily obviate the use of swsusp. It > would coexist alongside it.
Actually "dedicated partition" vs. "swap partition" is quite a small detail. It only affects disk allocation routines. Basic stuff like "atomic copy" stays the same...
> > > I understand you may not a rewrite of swsusp (regardless of how much > > > cleaner the code is), and I respect that. I'm completely willing to leave > > > kernel/suspend.c intact, and let you work in the integration into the > > > generic PM model, and/or simply rename the new code something like > > > swsusp2, swsusp-XP, or swsusp-pat. ;) > > > > So you want to develop swsusp-pat that will suspend to partition, > > allow another kernel version, and you think you can suspend when 90% > > of your memory is kmalloc()-ed? Do you agree that separate disk > > drivers for suspend is bad idea? > > Yes.
Do you think you can suspend with 90% memory kmalloc()-ed?
Pavel -- Horseback riding is like software... ...vgf orggre jura vgf serr. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |