On Fri, 20 Jul 2007, Rafael J. Wysocki wrote:
On Friday, 20 July 2007 01:07, [email protected] wrote:
On Thu, 19 Jul 2007, Rafael J. Wysocki wrote:
On Thursday, 19 July 2007 17:46, Milton Miller wrote:
The currently identified problems under discussion include:
(1) how to interact with acpi to enter into S4.
(2) how to identify which memory needs to be saved
(3) how to communicate where to save the memory
(4) what state should devices be in when switching kernels
(5) the complicated setup required with the current patch
(6) what code restores the image
(7) how to avoid corrupting filesystems mounted by the hibernated kernel
I didn't realize this was a discussion item. I thought the options were
clear, for some filesystem types you can mount them read-only, but for
ext3 (and possilby other less common ones) you just plain cannot touch
them.
That's correct. And since you cannot thouch ext3, you need either to assume
that you won't touch filesystems at all, or to have a code to recognize the
filesystem you're dealing with.
filesystem detection routines are already available
however, I'm the type to say that in a case like this where it matters you
should explicitly give the filesystem type anyway.
or the userspace helper functions that setup the instructions for the
hibernate warn you if you are telling it to mount a filesystem that it
knows is ext3 and is in use by the system going to sleep.
in any case there needs to be a big warning about this issue, but that's
different from saying "can't touch any filesystem that was mounted"
but under any other conditions you will eventually get enough memory free.
so try several times and if you still fail tell the user they have too
much stuff running and they need to kill something.
Well, with the freezer that's much simpler (and more reliable, I'd say): you
freeze tasks and _then_ you shrink memory.
this only works if you don't need tasks to do anything to free the memory.
(6) State of devices from before hibernation should be restored, if
possible
related to suspend should be transparent ... yes.
(7) On ACPI systems special platform-related actions have to be
carried out at
the right points, so that the platform works correctly after the
restore
I believe I have explained my suggestion.
(8) Hibernation and restore should not be too slow
We control the added code. We are using full runtime drivers and will
run at hardware speeds.
That may not be enough. If you're going to save, say, 80% of RAM on a 2 GB
machine, then you'll have to be using image compression.
this doesn't make sense, 20% of 2G is 400M, if you can't make a kernel and
userspace that can run in 400M you have a serious problem.
I was talking about the _speed_ of writing and reading.
if you are just talking about the I/O time for writing 2G of data, I
wouldn't worry about it. suspend isn't supposed to change the capabilities
of the system. if it takes a long time to do the I/O then that's how long
it takes.
being able to do compression or send the data elsewhere is a good thing,
but that's not something that is required to be supported in order to meet
some performance goal or consider the approach a failure.
All in all, we have three different and working implementation of the
image-writing and image-reading code at our disposal. Why would you want to
break the open doors?
becouse you say that the current methods won't work without ACPI support.
I didn't say that. [Or if I did, please point me to this message.]
I may have misunderstood you (I have deleted 90% of the messages in this
thread so I won't try to go back and find where I thought you said this)
Anyway, this wouldn't be true even if I did.
What I've been trying to say from the very beginning is that the current
frameworks _support_ hibernation a la ACPI S4 (although that's not exactly
ACPI S4) and if we are going to introduce a new framework, then it should
be designed to _support_ ACPI S4 fully _from_ _the_ _start_.
here is where there is some disagreement (although it may just be
misunderstanding on the 'fully support' phrase)
it sounds like you are saying that the ACPI support requires a lot of work
(the phrase I've seen some people use is a requirement to 'fix all the
drivers'). we aren't wanting to have this work prevent the non-ACPI
hibernation from progressing.
this isn't that we don't want the ACPI support eventually, it's in the
spirit of 'perfection is the enemy of good enough'
David Lang
This DOESN'T mean that the non-ACPI hibernation should be unsupported and
it DOESN"T mean that the non-ACPI hibernation is not supported currently.
IT IS SUPPORTED.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
