From: Pavel Machek <pavel@suse.cz>
To: hugang@soulinfo.com
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, Andi Kleen <ak@suse.de>,
Andrew Morton <akpm@osdl.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH][RFC] swsusp: speed up image restoring on x86-64
Date: Fri, 21 Jan 2005 11:30:28 +0100 [thread overview]
Message-ID: <20050121103028.GF18373@elf.ucw.cz> (raw)
In-Reply-To: <20050121022348.GA18166@hugang.soulinfo.com>
Hi!
> Full patch still can get from
> http://soulinfo.com/~hugang/swsusp/2005-1-21/
>From a short look:
core.eatmem.diff of course helps, but is wrong. You should talk to
akpm to find out why shrink_all_memory is not doing its job.
i386: + repz movsl %ds:(%esi),%es:(%edi)
I do not think movsl has any parameters. What is repz? Repeat as long
as it is non-zero? I think this should be "rep movsl".
core:
@@ -576,92 +989,31 @@ static void copy_data_pages(void)
for (zone_pfn = 0; zone_pfn < zone->spanned_pages; ++zone_pfn) {
if (saveable(zone, &zone_pfn)) {
struct page * page;
+ pbe = find_pbe_by_index(pagedir_nosave, nr_copy_pages-to_copy);
+ BUG_ON(pbe == NULL);
page = pfn_to_page(zone_pfn + zone->zone_start_pfn);
Don't you introduce O(n^2) behaviour here? Should not it be something
like pbe_next? And it is the only user of find_pbe_by_index().
I think that read_one_pbe() is too short to be uninlined... Same for
read_one_pagedir and write_one_pbe().
alloc_one_pagedir: why not just alloc page as zeroed?
Okay, it is still too big to merge directly. Would it be possible to
get mod_printk_progress(), introduce *_for_each (but leave there old
implementations), introduce pagedir_free() (but leave old
implementation). Better collision code should already be there, that
should make patch smaller, too. Try not to move code around.
That may be mergeable before 2.6.11...
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
next prev parent reply other threads:[~2005-01-21 10:31 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-20 19:32 Rafael J. Wysocki
2005-01-20 20:59 ` Pavel Machek
2005-01-20 21:46 ` Rafael J. Wysocki
2005-01-20 22:06 ` Pavel Machek
2005-01-20 22:58 ` Rafael J. Wysocki
2005-01-20 23:06 ` Pavel Machek
2005-01-21 0:14 ` Rafael J. Wysocki
2005-01-21 10:06 ` Pavel Machek
2005-01-21 12:43 ` Rafael J. Wysocki
2005-01-21 2:23 ` hugang
2005-01-21 10:04 ` Pavel Machek
2005-01-21 10:19 ` Andi Kleen
2005-01-21 10:30 ` Pavel Machek [this message]
2005-01-21 13:42 ` Rafael J. Wysocki
2005-01-21 14:31 ` hugang
2005-01-21 17:48 ` Pavel Machek
2005-01-21 12:32 ` Rafael J. Wysocki
2005-01-21 19:09 ` Rafael J. Wysocki
2005-01-22 2:03 ` Andi Kleen
2005-01-20 21:04 ` Rafael J. Wysocki
2005-01-22 2:50 ` Andi Kleen
2005-01-22 9:54 ` Pavel Machek
2005-01-22 11:26 ` Andi Kleen
2005-01-22 11:30 ` Pavel Machek
2005-01-22 11:44 ` Andi Kleen
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=20050121103028.GF18373@elf.ucw.cz \
--to=pavel@suse.cz \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=hugang@soulinfo.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rjw@sisk.pl \
/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
all inboxes | Powered by JetHome®