26 Sep, 2006

5 commits

  • Make swsusp use memory bitmaps to store its internal information during the
    resume phase of the suspend-resume cycle.

    If the pfns of saveable pages are saved during the suspend phase instead of
    the kernel virtual addresses of these pages, we can use them during the resume
    phase directly to set the corresponding bits in a memory bitmap. Then, this
    bitmap is used to mark the page frames corresponding to the pages that were
    saveable before the suspend (aka "unsafe" page frames).

    Next, we allocate as many page frames as needed to store the entire suspend
    image and make sure that there will be some extra free "safe" page frames for
    the list of PBEs constructed later. Subsequently, the image is loaded and, if
    possible, the data loaded from it are written into their "original" page
    frames (ie. the ones they had occupied before the suspend).

    The image data that cannot be written into their "original" page frames are
    loaded into "safe" page frames and their "original" kernel virtual addresses,
    as well as the addresses of the "safe" pages containing their copies, are
    stored in a list of PBEs. Finally, the list of PBEs is used to copy the
    remaining image data into their "original" page frames (this is done
    atomically, by the architecture-dependent parts of swsusp).

    Signed-off-by: Rafael J. Wysocki
    Acked-by: Pavel Machek
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Rafael J. Wysocki
     
  • Implement async reads for swsusp resuming.

    Crufty old PIII testbox:
    15.7 MB/s -> 20.3 MB/s

    Sony Vaio:
    14.6 MB/s -> 33.3 MB/s

    I didn't implement the post-resume bio_set_pages_dirty(). I don't really
    understand why resume needs to run set_page_dirty() against these pages.

    It might be a worry that this code modifies PG_Uptodate, PG_Error and
    PG_Locked against the image pages. Can this possibly affect the resumed-into
    kernel? Hopefully not, if we're atomically restoring its mem_map?

    Cc: Pavel Machek
    Cc: "Rafael J. Wysocki"
    Cc: Jens Axboe
    Cc: Laurent Riffard
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrew Morton
     
  • Add some instrumentation to the swsusp readin code to show what bandwidth
    we're achieving.

    Cc: Pavel Machek
    Cc: "Rafael J. Wysocki"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrew Morton
     
  • Switch the swsusp writeout code from 4k-at-a-time to 4MB-at-a-time.

    Crufty old PIII testbox:
    12.9 MB/s -> 20.9 MB/s

    Sony Vaio:
    14.7 MB/s -> 26.5 MB/s

    The implementation is crude. A better one would use larger BIOs, but wouldn't
    gain any performance.

    The memcpys will be mostly pipelined with the IO and basically come for free.

    The ENOMEM path has not been tested. It should be.

    Cc: Pavel Machek
    Cc: "Rafael J. Wysocki"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrew Morton
     
  • Add some instrumentation to the swsusp writeout code to show what bandwidth
    we're achieving.

    Cc: Pavel Machek
    Cc: "Rafael J. Wysocki"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrew Morton
     

11 Jul, 2006

2 commits


27 Mar, 2006

1 commit


23 Mar, 2006

1 commit