Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 

On Wednesday 22 February 2006 09:38, Rafael J. Wysocki wrote:
> On Tuesday 21 February 2006 22:00, Nigel Cunningham wrote:
> > On Wednesday 22 February 2006 06:40, Rafael J. Wysocki wrote:
> > > On Tuesday 21 February 2006 05:19, Dmitry Torokhov wrote:
> > > > On Monday 20 February 2006 21:57, Nigel Cunningham wrote:
> > > > > For the record, my thinking went: swsusp uses n (12?) bytes of meta
> > > > > data for every page you save, where as using bitmaps makes that
> > > > > much closer to a constant value (a small variable amount for
> > > > > recording where the image will be stored in extents). 12 bytes per
> > > > > page is 3MB/1GB. If swsusp was to add support for multiple swap
> > > > > partitions or writing to files, those requirements might be closer
> > > > > to 5MB/GB.
> > > >
> > > > 5MB/GB amounts to 0.5% overhead, I don't think you should be
> > > > concerned here. Much more important IMHO is that IIRC swsusp requires
> > > > to be able to free 1/2 of the physical memory whuch is hard on low
> > > > memory boxes.
> > >
> > > I see another point in using bitmaps: we could avoid modifying page
> > > flags and use bitmaps to store all of the temporary information.  I
> > > thought about it for some time and I think it's doable.
> >
> > It is doable - I'm doing it now, but am thinking about reverting part of
> > the code to use pbes again. If you're going to look at using bitmaps in
> > place of pbes, me changing would be a waste of time. Do you want me to
> > hold off for a while? (I'll happily do that, as I have far more than
> > enough to keep me occupied at the moment anyway).
>
> Well, I'd say so. :-)

Ok.

> Frankly, I didn't think of dropping PBEs right now, but in the long run
> that's worth considering, IMO.  The advantage of PBEs is that they are easy
> to handle in the assembly parts, but apart from this they are a bit
> wasteful (not very much, though).

Fully agree. That's why I've sought to keep the copying in c - it makes it 
simpler to read and maintain (although at the expense of a little bit of 
ugliness with that if in the stack page allocation or (old way) working hard 
to make the C not use stack).

> The fact that we use page flags to store some suspend/resume-related
> information is a big disadvantage in my view, and I'd like to get rid of
> that in the future.  In principle we could use a bitmap, or rather two of
> them, to store the same information independently of the page flags, and if
> we use bitmaps for this purpose, we can use them also instead of PBEs.

If you use the 'dynamically allocated pageflags' code (sure, pick a better 
name if you want), these changes will be pretty trivial - you can #define 
macros that could make the transition just a matter of switching PageNosave 
(eg) to PageSomethingElse. (Ditto for setting and clearing flags).

> At this point I'd have to look at your snapshot-related code and see if
> it's suitable for snapshot.c (in -mm now) somehow.  If you could point
> me to the specific parts of the suspend2 patch where this code is, I'd be
> grateful.

Sure. The bulk is in kernel/power/atomic_copy.c. Arch specific routines are 
include/asm-<arch>/suspend2.h.

Regards,

Nigel


> Greetings,
> Rafael

Attachment: pgpzuDVbWgqEn.pgp
Description: PGP signature

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux