From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Pavel Machek <pavel@suse.cz>
Cc: LKML <linux-kernel@vger.kernel.org>, Linux PM <linux-pm@osdl.org>
Subject: Re: [RFC][PATCH -mm 1/5] swsusp: Introduce memory bitmaps
Date: Wed, 9 Aug 2006 14:02:44 +0200 [thread overview]
Message-ID: <200608091402.44749.rjw@sisk.pl> (raw)
In-Reply-To: <20060809114628.GR3308@elf.ucw.cz>
Hi,
On Wednesday 09 August 2006 13:46, Pavel Machek wrote:
> > Introduce the memory bitmap data structure and make swsusp use in the suspend
> > phase.
]--snip--[
>
> Maybe that bitmap code should go to kernel/power/bitmaps.c or
> something?
Then we'll also need another header or put the definitions in power.h, but
they will only be used by the code in snapshot.c anyway. Apart from this,
the "bitmap" functions refer to alloc_image_page() etc. that are internal
to snapshot.c.
I thought it would be better to add this code to snapshot.c, because it's not
needed anywhere else and the separation of it would increase the overall
complexity for a little real gain.
> > +static inline void bm_position_reset_chunk(struct memory_bitmap *bm)
> > +{
> > + bm->cur.chunk = 0;
> > + bm->cur.bit = -1;
> > +}
> > +
> > +static void bm_position_reset(struct memory_bitmap *bm)
> > +{
> > + struct zone_bitmap *zone_bm;
> > +
> > + zone_bm = bm->zone_bm_list;
> > + bm->cur.zone_bm = zone_bm;
> > + bm->cur.block = zone_bm->bm_blocks;
> > + bm_position_reset_chunk(bm);
> > +}
> > +
> > +static void free_memory_bm(struct memory_bitmap *bm, int
> > clear_nosave_free);
>
> All your other functions use bm_XXX, this is XXX_bm. Well, you are
> mixing it rather freely..
OK, I'll change that to XXX_bm.
> > +/**
> > + * memory_bm_set_bit - set the bit in the bitmap @bm that corresponds
> > + * to given pfn. The cur_zone_bm member of @bm and the cur_block member
> > + * of @bm->cur_zone_bm are updated.
> > + *
> > + * If the bit cannot be set, the function returns -EINVAL .
> > + */
> > +
> > +static int
> > +memory_bm_set_bit(struct memory_bitmap *bm, unsigned long pfn)
> > +{
> > + struct zone_bitmap *zone_bm;
> > + struct bm_block *bb;
> > +
> > + /* Check if the pfn is from the current zone */
> > + zone_bm = bm->cur.zone_bm;
> > + if (pfn < zone_bm->start_pfn || pfn >= zone_bm->end_pfn) {
> > + zone_bm = bm->zone_bm_list;
> > + /* We don't assume that the zones are sorted by pfns */
> > + while (pfn < zone_bm->start_pfn || pfn >= zone_bm->end_pfn) {
> > + zone_bm = zone_bm->next;
> > + if (unlikely(!zone_bm))
> > + return -EINVAL;
> > + }
> > + bm->cur.zone_bm = zone_bm;
> > + }
> > + /* Check if the pfn corresponds to the current bitmap block */
> > + bb = zone_bm->cur_block;
> > + if (pfn < bb->start_pfn)
> > + bb = zone_bm->bm_blocks;
> > +
> > + while (pfn >= bb->end_pfn) {
> > + bb = bb->next;
> > + if (unlikely(!bb))
> > + return -EINVAL;
> > + }
> > + zone_bm->cur_block = bb;
> > + pfn -= bb->start_pfn;
> > + set_bit(pfn % BM_BITS_PER_CHUNK, bb->data + pfn / BM_BITS_PER_CHUNK);
> > + return 0;
> > +}
>
> It seems like this will not really introduce O(n^2) behaviour, since
> you are starting from last position each time?
Exactly.
> You have my ACK here,
Thanks. :-)
> but maybe it should go _after_ 4/5 and 5/5? Those are simple cleanups, this
> has break-something-potential and should rest in -mm for a while.
OK, I'll redo the series this way.
Rafael
next prev parent reply other threads:[~2006-08-09 12:08 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-09 9:52 [RFC][PATCH -mm 0/5] swsusp: Fix handling of highmem Rafael J. Wysocki
2006-08-09 9:58 ` [RFC][PATCH -mm 1/5] swsusp: Introduce memory bitmaps Rafael J. Wysocki
2006-08-09 10:31 ` Pavel Machek
2006-08-09 10:57 ` Rafael J. Wysocki
2006-08-09 11:27 ` Pavel Machek
2006-08-09 11:36 ` Rafael J. Wysocki
2006-08-09 11:53 ` Pavel Machek
2006-08-09 12:11 ` Rafael J. Wysocki
2006-08-09 11:46 ` Pavel Machek
2006-08-09 12:02 ` Rafael J. Wysocki [this message]
2006-08-09 13:35 ` Pavel Machek
2006-08-09 10:04 ` [RFC][PATCH -mm 2/5] swsusp: Use memory bitmaps during resume Rafael J. Wysocki
2006-08-09 10:34 ` Pavel Machek
2006-08-09 11:04 ` Rafael J. Wysocki
2006-08-09 11:33 ` Pavel Machek
2006-08-09 11:51 ` Rafael J. Wysocki
2006-08-09 13:33 ` Pavel Machek
2006-08-09 11:49 ` Pavel Machek
2006-08-09 12:04 ` Rafael J. Wysocki
2006-08-09 12:10 ` Pavel Machek
2006-08-09 10:09 ` [RFC][PATCH -mm 3/5] swsusp: Fix handling of highmem Rafael J. Wysocki
2006-08-09 11:51 ` Pavel Machek
2006-08-09 12:07 ` Rafael J. Wysocki
2006-08-09 13:35 ` Pavel Machek
2006-08-09 10:11 ` [RFC][PATCH -mm 4/5] swsusp: Change the name of pagedir_nosave Rafael J. Wysocki
2006-08-09 10:35 ` Pavel Machek
2006-08-09 10:13 ` [RFC][PATCH -mm 5/5] swsusp: Introduce some helpful constants Rafael J. Wysocki
2006-08-09 10:36 ` Pavel Machek
2006-08-09 10:47 ` [RFC][PATCH -mm 0/5] swsusp: Fix handling of highmem Nigel Cunningham
2006-08-09 11:38 ` Pavel Machek
2006-08-09 11:52 ` Nigel Cunningham
2006-08-13 22:34 ` 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=200608091402.44749.rjw@sisk.pl \
--to=rjw@sisk.pl \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@osdl.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