lkml.org 
[lkml]   [2006]   [Feb]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [ 01/10] [Suspend2] kernel/power/modules.h
    Date
    Hi,

    On Friday 03 February 2006 01:20, Nigel Cunningham wrote:
    > On Friday 03 February 2006 08:10, Rafael J. Wysocki wrote:
    > > I was referring to the (not so far) future situation when we have
    > > compression in the userland suspend/resume utilities. The times of
    > > writing/reading the image will be similar to yours and IMHO it's usually
    > > possible to free 1/2 of RAM in a box with 512+ MB of RAM at a little cost
    > > as far as the responsiveness after resume is concerned. Thus on machines
    > > with 512+ MB of RAM
    > > both solutions will give similar results performance-wise, but the
    > > userland-driven suspend gives you much more flexibility wrt what you can
    > > do with the image (eg. you can even send it over the network if need be).
    > >
    > > On machines with less RAM suspend2 will probably be better
    > > preformance-wise, and that may be more important than the flexibility.
    >
    > Ok. So I bit the bullet and downloaded -mm4 to take a look at this interface
    > you're making, and I have a few questions:
    >
    > - It seems to be hardwired to use swap, but you talk about writing to a
    > network image above. In Suspend2, I just bmap whatever the storage is, and
    > then submit bios to read and write the data. Is anything like that possible
    > with this interface? (Could it be extended if not?)

    The swap partition was easy. :-) However, there is the bmap() call that
    userspace processes can use, so it seems to be possible. [BTW, the network
    is easy too, because it desn't require us to tamper with disks while
    suspended.]

    > - Is there any way you could support doing a full image of memory with this
    > approach?

    I'm not sure, but I think that's possible. For now I don't see major
    obstacles, but honestly I'll have to read your code (and understand it)
    to answer this question responsibly.

    > Would you take patches?

    Well, the code in question is already in the kernel (in -mm, but this doesn't
    matter here) and I'm not the maintainer of it, so I can't answer this
    question directly. However, if you asked me whether I would _support_ any
    patches, I would say I had never opposed or supported a patch whithout trying
    to understand it.

    When I think I understand the patch, I try to value it, and I have two rules
    here:
    1) The released code should always be functional. [So I never submit
    untested patches without saying explicitly that they are untested and if I
    replace some code A with alternative code B, I do my best to ensure it
    won't break any existing setups.]
    2) The software with this patch applied must be such that I would like to run
    it on my computer. [If I wouldn't, there's no chance I'll support it.]

    > - Does the data have to be transferred to userspace? Security and efficiency
    > wise, it would seem to make a lot more sense just to be telling the kernel
    > where to write things and let it do bio calls like I'm doing at the moment.

    First, there's a difference between efficiency and performance.

    For example, the kernel already contains the code for writing data to the disk
    or partition you are using for suspend. By using bio directly to write to it
    you're duplicating the functionality of that code which is _inefficient_,
    although this need not be related to performance. Worse yet, if some
    optimizations go to this code, you won't have them unless you notice
    and implement them once again.

    Similar observation applies to enryption and compression: There are libraries
    for encryption and compression that contain lots of different algorithms,
    so why should we try to duplicate that code? It is more efficient to _use_
    it, which can be done easily in the user space.

    This may hurt performance a bit, but usually not so far that anyone will
    notice. [Actually on my box the suspending and resuming userland
    utilities I use for testing perform the I/O-related operations _faster_
    than the built-in swsusp code, although they seemingly do the same
    things.]

    Second, as far as the security is concerned, the only problem I see is that a
    malicious attacker may be able to read unencrypted suspend image from the
    system or submit his own specially crafted image which would require
    root-equivalent access anyway. However to prevent this you can set whatever
    paranoid permissions you desire on /dev/snapshot and implement your
    suspending utility as a daemon running in a privileged security ring (the
    resume is run from and initrd anyway).

    The biggest advantage of the userland-based approach I see is that there
    may be _many_ implementations of the suspending and resuming tools
    and they will not conflict. For example, if Distributor X needs an exotic feature
    Y wrt suspend (various vendor-specific eye-candies come to mind or
    transferring the image over a network), he can implement it in his userland
    tools without modifying the kernel. Similarly, if Vendor V wants to use paranoid
    encryption algorithm Z to encrypt the image, she can do that _herself_ in the
    user space.

    We only need to provide reference tools and we won't be asked to implement
    every feature that people may want in the kernel.

    > - In your Documentation file, you say say opening /dev/snapshot for reading is
    > done when suspending. Shouldn't that be open read for resume and write for
    > suspend?

    No. During suspend the image is read from the kernel and saved by a userland
    tool and analogously during resume.

    > I'm not saying I'm going to get carried away trying to port Suspend2 to
    > userspace. Just tentatively exploring. But if I did decide to port it, my
    > default position would be to seek not to drop a single feature. I hope that's
    > not too unreasonable!

    That's fine. I think we have the same goal which is a reasonable set of
    features available to the users.

    [Heh, that looks like a good starter for the userland suspend FAQ. Perhaps
    I should save this message. ;-)]

    Greetings,
    Rafael
    -
    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/

    \
     
     \ /
      Last update: 2006-02-03 10:01    [W:2.287 / U:0.032 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site