Both suspend-to-disk and suspend-to-ram are controlled by echo <num> > /proc/acpi/sleep.
If you are using apm, i have no idea how that works.
Anyway, depending on acpi is wrong and needs to be fixed in 2.7.
--p
Thus wrote [email protected]:
> Anyway, depending on acpi is wrong and needs to be fixed in 2.7.
Could you elaborate on that? Do you mean S4, or any suspend state in
general?
Best regards,
--
Karol 'sziwan' Kozimor
[email protected]
Hi!
> Thus wrote [email protected]:
> > Anyway, depending on acpi is wrong and needs to be fixed in 2.7.
>
> Could you elaborate on that? Do you mean S4, or any suspend state in
> general?
It would be nice to have arch-neutral way to enter suspend to ram and
suspend to disk. Being arch-neutral, it may not depend on ACPI.
Pavel
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
>
> Hi!
>
> > Thus wrote [email protected]:
> > > Anyway, depending on acpi is wrong and needs to be fixed in 2.7.
> >
> > Could you elaborate on that? Do you mean S4, or any suspend state in
> > general?
>
> It would be nice to have arch-neutral way to enter suspend to ram and
> suspend to disk. Being arch-neutral, it may not depend on ACPI.
Taking this in a slightly different direction.
It would be even nicer to be able to be able to migrate machine images
between machines.
How identical do machines have to be before it's no longer just a case
of copying the file?
Identical make of RAM, same CPU model, same BIOS version, with the PCI and
USB things connected to the same slots in the same way?
Or is it a little looser?
Hi!
> > > > Anyway, depending on acpi is wrong and needs to be fixed in 2.7.
> > >
> > > Could you elaborate on that? Do you mean S4, or any suspend state in
> > > general?
> >
> > It would be nice to have arch-neutral way to enter suspend to ram and
> > suspend to disk. Being arch-neutral, it may not depend on ACPI.
>
> Taking this in a slightly different direction.
>
> It would be even nicer to be able to be able to migrate machine images
> between machines.
> How identical do machines have to be before it's no longer just a case
> of copying the file?
> Identical make of RAM, same CPU model, same BIOS version, with the PCI and
> USB things connected to the same slots in the same way?
> Or is it a little looser?
Well, for USB maybe hotplug would handle the change, all the other
stuff should better be the same.
It probably will work even with (for example) slightly different BIOS
version, but... don't count on that.
If you want to migrate programs between machines, run UMLinux, same
config, on both machines. Ouch and you'll need swsusp for UMLinux, too
;-).
Pavel
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
On Wed, Jul 16, 2003 at 12:40:26PM +0200, Pavel Machek wrote:
> If you want to migrate programs between machines, run UMLinux, same
> config, on both machines. Ouch and you'll need swsusp for UMLinux, too
That might be more important than you think.
Just start your Oracle in UML and swsusp. Now start your loadbalancer and start
a copy of that frozen image as soon, as the load reaches a defined limit and
kill these images again, if load goes down.
There might be even more interesting scenarios like this.
Regards
Ingo Oeser
Hi!
> > If you want to migrate programs between machines, run UMLinux, same
> > config, on both machines. Ouch and you'll need swsusp for UMLinux, too
>
> That might be more important than you think.
:-). Well, it is also harder than you probably think, because UML is
*very* strange architecture and it is not at all easy to save/restore
its state. There were some patches in that area, but it never worked
(AFAIK).
> Just start your Oracle in UML and swsusp. Now start your loadbalancer and start
> a copy of that frozen image as soon, as the load reaches a defined limit and
> kill these images again, if load goes down.
Not *my* Oracle ;-).
Pavel
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
On Mer, 2003-07-16 at 19:15, Pavel Machek wrote:
> Hi!
>
> > > If you want to migrate programs between machines, run UMLinux, same
> > > config, on both machines. Ouch and you'll need swsusp for UMLinux, too
> >
> > That might be more important than you think.
>
> :-). Well, it is also harder than you probably think, because UML is
> *very* strange architecture and it is not at all easy to save/restore
> its state. There were some patches in that area, but it never worked
> (AFAIK).
Would it not be a lot easier to tackle that with qemu, and teach qemu to
freeze/restore virtual machines ?
On Wed, Jul 16, 2003 at 08:17:24PM +0100, Alan Cox wrote:
> On Mer, 2003-07-16 at 19:15, Pavel Machek wrote:
> > Hi!
> >
> > > > If you want to migrate programs between machines, run UMLinux, same
> > > > config, on both machines. Ouch and you'll need swsusp for UMLinux, too
> > >
> > > That might be more important than you think.
> >
> > :-). Well, it is also harder than you probably think, because UML is
> > *very* strange architecture and it is not at all easy to save/restore
> > its state. There were some patches in that area, but it never worked
> > (AFAIK).
>
> Would it not be a lot easier to tackle that with qemu, and teach qemu to
> freeze/restore virtual machines ?
AFAIK, qemu does virtual processes, but not virtual machines. Running init(1)
from qemu could be fun, anyways ;)
Greets, Antonio.
--
In fact, this is all you need to know to be
a Caveman Database Programmer:
A relational database is a big spreadsheet
that several people can update simultaneously.
On Mer, 2003-07-16 at 23:39, Antonio Vargas wrote:
> > Would it not be a lot easier to tackle that with qemu, and teach qemu to
> > freeze/restore virtual machines ?
>
> AFAIK, qemu does virtual processes, but not virtual machines. Running init(1)
> from qemu could be fun, anyways ;)
qemu moves on release by release. It can run an entire virtualised linux kernel
nowdays, although its performance still needs some work.
Hi!
> > > Would it not be a lot easier to tackle that with qemu, and teach qemu to
> > > freeze/restore virtual machines ?
> >
> > AFAIK, qemu does virtual processes, but not virtual machines. Running init(1)
> > from qemu could be fun, anyways ;)
>
> qemu moves on release by release. It can run an entire virtualised linux kernel
> nowdays, although its performance still needs some work.
I guess qemu is way too slow for this.
Pavel
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
On Iau, 2003-07-17 at 17:29, Pavel Machek wrote:
> > qemu moves on release by release. It can run an entire virtualised linux kernel
> > nowdays, although its performance still needs some work.
>
> I guess qemu is way too slow for this.
Its coming in about 25% of native performance so certainly has a way to go yet