[lkml]   [2003]   [Mar]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: SWSUSP Discontiguous pagedir patch

> > 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?

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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:33    [W:0.112 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site