From: Pavel Machek <pavel@ucw.cz>
To: Patrick Mochel <mochel@osdl.org>
Cc: Nigel Cunningham <ncunningham@clear.net.nz>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: SWSUSP Discontiguous pagedir patch
Date: Fri, 7 Mar 2003 21:27:59 +0100 [thread overview]
Message-ID: <20030307202759.GA2447@elf.ucw.cz> (raw)
In-Reply-To: <Pine.LNX.4.33.0303070950030.991-100000@localhost.localdomain>
Hi!
> > > All in all, I think the idea of saving state to swap is dangerous for
> > > various reasons. However, I like some of the other concepts of the code,
> >
> > Can you elaborate? I believe writing
> > to swap is good for user; and it works.
>
> It does work, but there are uncertainties inherently present when using
> such a solution. Some of them were just the behavior of the current code,
> which I fixed, like:
>
> - Only ever using the first swap partition, regardless of space
> left.
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).
> - Not resetting swap signature if a resume failed.
Can be fixed in userland. Add option -s that for mkswap that fixes
signature only if it was overwritten by suspend, and add mkswap -s
/swap/partiton in your init scripts.
> - Almost complete lack of a recovery path if anything failed (i.e. trying
> to back out of what has happened, instead of calling BUG() or
> panic()).
Those BUGs / panics should be impossible to trigger. [And this has
nothing to do with fact we suspend-to-swap].
> - Function names like do_magic() and friends.
It is pretty magical operation, so you are at least warned. [And this has
nothing to do with fact we suspend-to-swap].
> This types of things don't instill any confidence in a user or other
> developer looking at the code. It gives the impression that the code is
> the result of blind guess work in the dark. After looking at the code, it
> was a shock to me that it worked at all.
>
> I understand that getting it to work involves dealing with the
> uncertainties. However, there is no reason to pass them on to other users.
> There were no comments as to what the do_magic*() functions did, let alone
> why they were 'magic', and there were 5 of them.
do_magic() replaces one kernel with another. That seems magical enough
to me. [It is in 5 functions so that the real hard part can be in
assembly].
> There are uncertainties still present in the code, like
>
> - #warning about waiting for data to reach the disk.
>
> - "Waiting for DMAs to settle down" delay on resume.
>
> I respect the paranoia. Howver, it's things like these that should be
> dealt with before anything else.
Feel free to fix them. [I believe both warning and waiting for DMA can
be safely killed, but...]
> The general problems that I see with the solution are:
>
> - It simply won't work if you're low on swap or memory.
Your solution will not work with too small suspend partition
too. Being low on memory... You'd have to have > 50% of your memory
allocated by kernel for swsusp to fail. I do not think it can be
sanely done other way. [Having separate disk drivers just for suspend
is *not* sane.]
> - It won't work if you're swap is not persistant across reboots.
Your solution will not work if your suspend partition is not
persistant across reboots. AND WHAT?
> - It won't work if you don't use swap.
Your solution will not work if your suspend partition is not there.
> - It's dependent on the same exact kernel being loaded.
>
> It should only be dependent on the binary format of the written metadata.
...which leads to simpler design and few megabytes less transfered to
/ from disk. I do not think there's easy way to do it with different
kernels. State of devices before switching to new kernel is important...
> It also shouldn't be waiting until all the devices are probed and
> initialized, but that problem is out of your hands.
>
> Another problem I see in the future is initramfs, and when things start
> executing in there. It's currently unpacked by populate_rootfs() in
> init/main.c, long before software_resume() is called. Though it doesn't
> cause any explicit problems ATM, it does introduce more
> uncertainties.
Oops, I have not seen that one. Yep that may turn nasty in
future. software_resume() should really be done before userland starts.
> I don't want to cast the entire project in a negative light, though. It
> does work, and I'm fairly impressed by it.
Thanx.
> I've created a registration mechanism for PM 'drivers', and a way for
> users to select which driver they want to use for the different PM states.
> In the patch, swsusp is just another driver. It can coexist with ACPI or
> APM (theoretically) just fine, without requiring a kernel rebuild or
> reboot.
I believe it can coexist with ACPI and APM already just okay. You can
echo 4b to /proc/acpi/sleep to trigger S4bios.
> This also involves a generic framework for doing system-wide power
> management. In this, I've begun extracting bits from swsusp that are
> useful for any PM sequence. My goal is to reduce swsusp to just a small
> layer that writes/reads the saved pages from swap. The rest of the
> sequence, including memory and device handling, happens in generic
> code.
So you don't really want to create separate "suspend partition"? Good.
More sharing between S3 and S4 is certainly good (but I do not think
much more can be shared).
> > > http://ldm.bkbits.net:8080/linux-2.5-power
> > >
> >
> > Can you post cumulative diff of work-in-progress?
> > I am not permitted to use bk. Also please
> > make sure that you post the diff before
> > you merge it (and please Cc me).
>
> Sure. From the above link, you can view the individual patches. I would
> hope that you could use wget to snarf them, though I don't know if that's
> legally ok (nor do I want to know).
>
> The cumulative patch is here:
>
> > >http://kernel.org/pub/linux/kernel/people/mochel/power/pm-2.5.64.diff.gz
THenx.
> If I get a chance in the next few days, I'll post incremental diffs.
> Without them, the gradual changes are not so obvious.
>
> 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?
Pavel
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
next prev parent reply other threads:[~2003-03-07 20:18 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1045784829.3821.10.camel@laptop-linux.cunninghams>
[not found] ` <20030223223757.GA120@elf.ucw.cz>
[not found] ` <1046136752.1784.15.camel@laptop-linux.cunninghams>
[not found] ` <20030227132024.GB27084@atrey.karlin.mff.cuni.cz>
2003-02-27 18:42 ` SWSUSP Discontiguous pagedirs Nigel Cunningham
2003-03-01 4:22 ` SWSUSP Discontiguous pagedir patch Nigel Cunningham
2003-03-02 23:55 ` Patrick Mochel
2003-03-03 2:06 ` Nigel Cunningham
2003-03-03 2:31 ` Nigel Cunningham
2003-03-03 12:30 ` Pavel Machek
2003-03-04 20:36 ` Patrick Mochel
2003-03-05 20:50 ` Pavel Machek
2003-03-05 21:52 ` Linux vs Windows temperature anomaly Jonathan Lundell
2003-03-05 23:11 ` Herman Oosthuysen
2003-03-05 23:38 ` Con Kolivas
2003-03-05 23:50 ` Russell King
2003-03-06 0:29 ` Ed Sweetman
2003-03-06 0:47 ` Trever L. Adams
2003-03-06 9:45 ` Russell King
2003-03-06 1:58 ` Jonathan Lundell
2003-03-06 7:18 ` Corvus Corax
2003-03-06 7:57 ` Ed Sweetman
2003-03-06 8:18 ` Corvus Corax
2003-03-06 8:58 ` Ed Sweetman
2003-03-06 15:41 ` Jesse Pollard
2003-03-06 14:27 ` Jesse Pollard
2003-03-06 2:57 ` David Rees
2003-03-06 6:12 ` Matthias Schniedermeyer
2003-03-06 16:07 ` Jonathan Lundell
2003-03-07 0:40 ` Horst von Brand
2003-03-05 18:02 ` SWSUSP Discontiguous pagedir patch Pavel Machek
2003-03-07 17:14 ` Patrick Mochel
2003-03-07 20:27 ` Pavel Machek [this message]
2003-03-09 19:39 ` Benjamin Herrenschmidt
2003-03-09 20:12 ` Pavel Machek
2003-03-10 16:49 ` Patrick Mochel
2003-03-10 19:23 ` Pavel Machek
2003-03-10 19:05 ` Patrick Mochel
2003-03-10 22:17 ` Nigel Cunningham
2003-03-10 23:20 ` Pavel Machek
2003-03-07 20:36 ` Pavel Machek
2003-03-10 16:51 ` Patrick Mochel
2003-03-10 19:12 ` Pavel Machek
2003-03-10 18:59 ` Patrick Mochel
2003-03-07 20:41 ` Pavel Machek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030307202759.GA2447@elf.ucw.cz \
--to=pavel@ucw.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=mochel@osdl.org \
--cc=ncunningham@clear.net.nz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).