mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Pavel Machek <pavel@suse.cz>
Cc: hugang@soulinfo.com, 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 14:42:54 +0100	[thread overview]
Message-ID: <200501211442.55274.rjw@sisk.pl> (raw)
In-Reply-To: <20050121103028.GF18373@elf.ucw.cz>

Hi,

On Friday, 21 of January 2005 11:30, Pavel Machek wrote:
> 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?

No, it's "repeat until %ecx is zero or ZF is cleared", but the latter never happens
with movsl.  It's intended for cmpsl, scasl and friends (the assembler should
complain about using it here).

> I think this should be "rep movsl".

Yes, it should.


> 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.

I have a suggestion.

hugang, you are currently replacing an array of pbes with a list of arrays
of pbes contained within individual pages.

I would go further and replace it with a single one-directional list
of pbes.  Namely, I would modify "struct pbe" in the following way:

struct pbe {
	unsigned long address;
	unsigned long orig_address;
	swp_entry_t swap_address;	
	struct pbe *next;
};

(AFAICT, the "dummy" field is only used by hugang - as a pointer)
and I would define "for_each_pbe()" as:

#define for_each_pbe(pbe, pblist) \
	for (pbe = pblist;  pbe;  pbe = pbe->next)

Then, the only non-trivial changes would be in alloc_pagedir() and
in swsusp_pagedir_relocate(), where I would need to link pbes to
each other.

This also would make the assembly parts independent of the
sizeof(struct pbe), which is currently hardcoded there.

What do you think?

Greets,
RJW


-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
		-- Lewis Carroll "Alice's Adventures in Wonderland"

  reply	other threads:[~2005-01-21 13:49 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
2005-01-21 13:42         ` Rafael J. Wysocki [this message]
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=200501211442.55274.rjw@sisk.pl \
    --to=rjw@sisk.pl \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=hugang@soulinfo.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@suse.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

Powered by JetHome