lkml.org 
[lkml]   [2006]   [May]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH -mm] swsusp: support creating bigger images (rev. 2)
    Date
    Hi Andrew et al.

    On Thursday 11 May 2006 09:38, Andrew Morton wrote:
    > "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
    > > On Wednesday 10 May 2006 00:27, Andrew Morton wrote:
    > > > "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
    > > > > Now if the mapped pages that are not mapped by the
    > > > > current task are considered, it turns out that they would change
    > > > > only if they were reclaimed by try_to_free_pages().  Thus if we take
    > > > > them out of reach of try_to_free_pages(), for example by
    > > > > (temporarily) moving them out of their respective LRU lists after
    > > > > creating the image, we will be able to include them in the image
    > > > > without copying.
    > > >
    > > > I'm a bit curious about how this is true. There are all sorts of way
    > > > in which there could be activity against these pages - interrupt-time
    > > > asynchronous network Tx completion, async interrupt-time direct-io
    > > > completion, tasklets, schedule_work(), etc, etc.
    > >
    > > AFAIK, many of these things are waited for uninterruptibly, and
    > > uninterruptible tasks cannot be frozen.
    >
    > There can be situations where we won't be waiting on this IO at all.
    > Network zero-copy transmit, for example.
    >
    > Or maybe there's some async writeback going on against pagecache - we'll
    > end up looking at the page's LRU state within interrupt context at IO
    > completion. (A sync would prevent this from happening).

    I believe more than a sync is needed in at least some cases. I've seen XFS
    continue to submit I/O (presumably on the sb or such like) after everything
    else has been frozen and data has been synced. Freezing bdevs addressed this.

    > One possibly problematic scenario is where task A is doing a direct-IO read
    > and task B truncates the same file - here, the page will be actually
    > removed from the LRU and freed in interrupt context. The direct-IO read
    > process will be waiting on the IO in D state though. It it was a
    > synchronous read - if it was an AIO read then it won't be waiting on the
    > IO. Something else might save us here, but it's fragile.

    Bdev freezing helps here too, right?

    > > Theoretically we may have a problem if there's an
    > > interruptible task that waits for the completion of an operation that
    > > gets finished after snapshotting the system. However that would have to
    > > survive the syncing of filesystems, freezing of kernel threads, freeing
    > > of memory as well as suspending and resuming all devices. [In which case
    > > it would be starving to death. :-)]

    (For Rafael/Pavel): The swsusp version of the refrigerator signals these
    processes to enter the freezer too, just in case the uninterruptible task
    does continue, right?

    Regards,

    Nigel

    > hm. It's all a bit of a worry. I don't understand what swsusp is trying
    > to do here sufficiently well to be able to advise, sorry. I was rather
    > surprised to learn that it's presently taking copies of all these pages...
    > -
    > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    > the body of a message to majordomo@vger.kernel.org
    > More majordomo info at http://vger.kernel.org/majordomo-info.html
    > Please read the FAQ at http://www.tux.org/lkml/
    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2006-05-11 02:14    [W:0.023 / U:1.924 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site