lkml.org 
[lkml]   [2010]   [Nov]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [Ksummit-2010-discuss] checkpoint-restart: naked patch
    Thanks Tejun,

    your writeup brought up a lot of the same issues that I see with
    the in-kernel C/R. Various C/R implementations that are entirely
    in userspace or with limited kernel assistance have been in production
    in HPC environments for years. I think especially for these workloads
    C/R is an extremly useful feature, and a standard implementation would
    do Linux well.

    But I think the "transparent" in-kernel one is the wrong approach. It
    tries to give the illusion that C/R will just work, while a lot of
    things are simply not support. In this case whitelisting the allowed
    state by requiring special APIs for all I/O (or even just standard
    APIs as long as they are supposed by the C/R lib you're linked against)
    is the more pragmatic, and I think faithful aproach. In addition to
    the amount of state not supported despite looking transparant the
    other big problem with the patchset is that it saves the kernel internal
    state which changes all the time from one release to another. The
    handwaiving is that a userspace tool will solve it. I'm pretty sure
    that's not the case; it might solve a few cases but the general
    version n to version m conversion is impossible to maintain. Just look
    at the problem qemu has migration between just a handfull of version
    of the relatively well (compared to random kernel state) defined vmstate
    format.




    \
     
     \ /
      Last update: 2010-11-02 22:53    [W:0.022 / U:58.492 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site