public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Nigel Cunningham <ncunningham@clear.net.nz>
To: "Martin J. Bligh" <mbligh@aracnet.com>
Cc: Pavel Machek <pavel@ucw.cz>,
	"Grover, Andrew" <andrew.grover@intel.com>,
	Marc Giger <gigerstyle@gmx.ch>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Linux Kernel Development <linux-kernel@vger.kernel.org>
Subject: Re: Fix SWSUSP & !SWAP
Date: Thu, 24 Apr 2003 15:17:26 +1200	[thread overview]
Message-ID: <1051152437.2453.26.camel@laptop-linux> (raw)
In-Reply-To: <1605730000.1051145146@flay>

On Thu, 2003-04-24 at 12:45, Martin J. Bligh wrote:
> > I don't believer I've ever seen things get OOM killed. Instead, page
> > cache is discarded until things do fit.
> 
> What happens if user allocated pages are filling up all the space,
> not page cache? Trust me, it happens ;-)

Yep, just because I haven't seen it, doesn't mean a thing. :>. In that
case, there are two issues: memory to work in to start with and how to
save the image without corrupting it.

Regarding #1, there must still be some memory available, mustn't there?
swsusp only approx (nrpages in use/256) pages to do its work. Surely
we'd always be able to get .4% of the number of pages? Even if we can't
get that many, we should be able to adjust the algorithm to be able to
suspend a machine with only 10 or so pages available to start with (no,
I'm not volunteering to do it! I want to merge with 2.5 and get on to
other projects!).

Regarding #2, my algorithm (ie not the version in 2.5 at the mo)
separates pages to be saved into 2 types. Pageset1 are pages we expect
to be needed during suspend. Pageset2 is those that will definitely not
be needed. My algorithm for saving the data goes: Save pageset2 pages to
disk then (as per the original/current method) make a copy of pageset1
pages (using the pageset2 locations + extra allocated memory if needsbe)
and save the copy. Loading the image is the reverse process. Pageset 2
currently only consists of all highmem pages + active and inactive list
pages. If we refined the algorithm, perhaps that would address your
issue. The other point here is that since we have to be able to make a
copy of pageset1 pages, and since I haven't inlined kmap/unmap in the
routine to copy pageset1 pages back on resume (Pavel will say whew to
that, I'm sure!), pageset1 has a miximum size of half normal memory. I
reckon refining the algoritm so that pageset1 can be [nearly] guaranteed
to always be smaller is the better area to focus on, and I'm perfectly
happy to try suggestions, particularly when they come in the form of a
code fragment that include a call to SetPagePageset2(struct page * page)
for the relevant targets :>

Regards,

Nigel
-- 
Nigel Cunningham
495 St Georges Road South, Hastings 4201, New Zealand

Be diligent to present yourself approved to God as a workman who does
not need to be ashamed, handling accurately the word of truth.
	-- 2 Timothy 2:14, NASB.


  reply	other threads:[~2003-04-24  3:10 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-23 23:47 Fix SWSUSP & !SWAP Grover, Andrew
2003-04-24  0:03 ` Pavel Machek
2003-04-23 23:57   ` Martin J. Bligh
2003-04-24  0:25     ` Pavel Machek
2003-04-24  0:37       ` CaT
2003-04-24  0:49       ` Martin J. Bligh
2003-04-24  9:16         ` Pavel Machek
2003-04-24  0:02   ` Nigel Cunningham
2003-04-24  0:23     ` Pavel Machek
2003-04-24  0:45     ` Martin J. Bligh
2003-04-24  3:17       ` Nigel Cunningham [this message]
2003-04-24  4:37         ` Martin J. Bligh
2003-04-24  7:49           ` Marc Giger
2003-04-24  9:27           ` Pavel Machek
2003-04-24  3:49   ` David Ford
2003-04-24  6:54     ` Jörn Engel
2003-04-24  7:01     ` Elladan
  -- strict thread matches above, loose matches on Subject: below --
2003-04-23 13:51 Pavel Machek
2003-04-23 14:32 ` Geert Uytterhoeven
2003-04-23 14:47   ` Pavel Machek
2003-04-23 15:56     ` gigerstyle
2003-04-23 19:41       ` Nigel Cunningham
2003-04-23 20:36         ` Marc Giger
2003-04-23 22:25           ` Nigel Cunningham
2003-04-23 23:28             ` Martin J. Bligh
2003-04-23 23:58               ` Pavel Machek
2003-04-23 23:55                 ` Martin J. Bligh
2003-04-24  0:07                 ` Andrew Morton
2003-04-24  0:17                   ` CaT
2003-04-24  0:16                     ` Nigel Cunningham
2003-04-24  0:26                       ` Randy.Dunlap
2003-04-24  0:31                         ` CaT
2003-04-24  0:38                         ` Andrew Morton
2003-04-24  0:54                           ` CaT
2003-04-24  1:06                             ` Andrew Morton
2003-04-24  8:48                           ` John Bradford
2003-04-24  0:37                       ` Andrew Morton
2003-04-24  9:12                         ` Pavel Machek
2003-04-24  9:25                           ` Andrew Morton
2003-04-24  9:35                             ` Pavel Machek
2003-04-24  9:46                               ` Andrew Morton
2003-04-24 11:13                                 ` Nigel Cunningham
2003-04-24 11:36                                   ` Andrew Morton
2003-04-24 14:26                                     ` Pavel Machek
2003-04-24 16:37                                       ` Andreas Dilger
2003-04-24 20:48                                         ` Pavel Machek
2003-04-24 21:46                                           ` Andreas Dilger
2003-04-25  1:09                                             ` Nigel Cunningham
2003-04-25 12:59                                               ` Pavel Machek
2003-04-25 16:20                                                 ` Andreas Dilger
2003-04-25 18:28                                                   ` Nigel Cunningham
2003-04-25 19:32                                                     ` Jamie Lokier
2003-04-25 19:58                                                     ` Andreas Dilger
2003-04-27 18:59                                                   ` Pavel Machek
2003-04-24 11:36                                   ` Geert Uytterhoeven
2003-04-25  1:22                                     ` H. Peter Anvin
2003-04-25  1:19                                       ` Nigel Cunningham
2003-04-25  1:31                                       ` Hua Zhong
2003-04-25 19:41                                         ` H. Peter Anvin
2003-04-25  4:27                                       ` Andreas Dilger
2003-04-25  4:33                                         ` H. Peter Anvin
2003-04-24  0:25                   ` Pavel Machek
2003-04-24  9:01                     ` Andrew Morton
2003-04-24  9:14                       ` Pavel Machek
2003-04-24  9:05                     ` Jamie Lokier
2003-04-24  9:34                       ` Pavel Machek
2003-04-24 15:22                     ` Carl-Daniel Hailfinger
2003-04-24  8:00             ` Marc Giger

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=1051152437.2453.26.camel@laptop-linux \
    --to=ncunningham@clear.net.nz \
    --cc=andrew.grover@intel.com \
    --cc=geert@linux-m68k.org \
    --cc=gigerstyle@gmx.ch \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbligh@aracnet.com \
    --cc=pavel@ucw.cz \
    /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