lkml.org 
[lkml]   [2006]   [Aug]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [RFC][PATCH -mm 0/5] swsusp: Fix handling of highmem
    Date
    Hi.

    On Wednesday 09 August 2006 19:52, Rafael J. Wysocki wrote:
    > Hi,
    >
    > Currently swsusp handles highmem in a simplistic way, by trying to store a
    > copy of each saveable highmem page in the "normal" memory before creating
    > the suspend image. These copies are then copied once again before saving,
    > because they are treated as any other non-highmem pages with data. For
    > this reason, to save one highmem page swsusp needs two free pages in the
    > "normal" memory, so on a system with high memory it is practically
    > impossible to create a suspend image above 400 kilobytes. Moreover, if
    > there's much more highmem than the "normal" memory in the system, it may be
    > impossible to suspend at all due to the lack of space for saving
    > non-freeable highmem pages.
    >
    > This limitation may be overcome in a satisfactory way if swsusp does its
    > best to store the copies of saveable highmem pages in the highmem itself.
    > However, for this purpose swsusp has to be taught to use pfns, or (struct
    > page *) pointers, instead of kernel virtual addresses to identify memory
    > pages. Yet, if this is to be implemented, we can also attack the minor
    > problem that the current swsusp's internal data structure, the list of page
    > backup entries (aka PBEs), is not very efficient as far as the memory usage
    > is concerned.
    >
    > This issue can be addressed by replacing the list of PBEs with a pair of
    > memory bitmaps. Still, to remove the list of PBEs completely, we would
    > have to make some complicated modifications to the architecture-dependent
    > parts of the code which would be quite undesirable. However, we can use
    > the observation that memory is only a limiting resource during the suspend
    > phase of the suspend-resume cycle, because during the resume phase
    > many image pages may be loaded directly to their "original" page frames, so
    > we don't need to keep a copy of each of them in the memory. Thus the list
    > of PBEs may be used safely in the last part of the resume phase without
    > limitting the amount of memory we can use.
    >
    > The following series of patches introduces the memory bitmap data
    > structure, makes swsusp use it to store its internal information and
    > implements the improved handling of saveable highmem pages.
    >
    > Comments welcome.

    Thanks for the reminder. I'd forgotten half the reason why I didn't want to
    make Suspend2 into incremental patches! You're a brave man!

    Nigel
    --
    while (1) {
    size=$RANDOM * 65536 + 1
    dd if=/dev/random bs=1 count=$size | patch -p0-b
    make && break
    }
    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2006-08-09 13:09    [W:0.048 / U:0.052 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site