lkml.org 
[lkml]   [2006]   [Feb]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [ 00/10] [Suspend2] Modules support.
    Date
    Hi.

    On Saturday 04 February 2006 20:58, Rafael J. Wysocki wrote:
    > Hi,
    >
    > On Saturday 04 February 2006 10:54, Nigel Cunningham wrote:
    > > On Saturday 04 February 2006 19:01, Pavel Machek wrote:
    > > > On So 04-02-06 11:20:54, Nigel Cunningham wrote:
    > > > > Hi Pavel.
    > > > >
    > > > > On Friday 03 February 2006 21:44, Pavel Machek wrote:
    > > > > > [Pavel is willing to take patches, as his cooperation with
    > > > > > Rafael shows, but is scared by both big patches and series of 10
    > > > > > small patches he does not understand. He likes patches removing
    > > > > > code.]
    > > > >
    > > > > Assuming you're refering to the patches that started this thread,
    > > > > what don't you understand? I'm more than happy to explain.
    > > >
    > > > For "suspend2: modules support", it is pretty clear that I do not
    > > > need or want that complexity. But for "refrigerator improvements", I
    > > > did
    > >
    > > ... and yet you're perfectly happy to add the complexity of sticking
    > > half the code in userspace. I don't think I'll ever dare to try to
    > > understand you, Pavel :)
    > >
    > > > not understand which parts are neccessary because of suspend2
    > > > vs. swsusp differences, and if there is simpler way towards the same
    > > > goal. (And thanks for a stress hint...)
    > >
    > > I think virtually everything is relevant to you.
    >
    > My personal view is that:
    > 1) turning the freezing of kernel threads upside-down is not necessary
    > and would cause problems in the long run,

    Upside down?

    > 2) the todo lists are not necessary and add a lot of complexity,

    Sorry. Forgot about this. I liked it for solving the SMP problem, but IIRC,
    we're downing other cpus before this now, so that issue has gone away. I
    should check whether I'm right there.

    > 3) trying to treat uninterruptible tasks as non-freezeable should better
    > be avoided (I tried to implement this in swsusp last year but it caused
    > vigorous opposition to appear, and it was not Pavel ;-))

    I'm not suggesting treating them as unfreezeable in the fullest sense. I
    still signal them, but don't mind if they don't respond. This way, if they
    do leave that state for some reason (timeout?) at some point, they still
    get frozen.

    > > A couple of possible exceptions might be (1) freezing bdevs,
    > > because you don't care so much about making xfs really sync and really
    > > stop it's activity
    >
    > As I have already stated, in my view this one is at least worth
    > considering in the long run.
    >
    > > and (2) the ability to thaw kernel space without thawing userspace. I
    > > want this for eating memory, to avoid deadlocking against kjournald
    > > etc. I haven't checked carefully as to why you don't need it in
    > > vanilla.
    >
    > Because it does not deadlock? I will say we need this if I see a
    > testcase showing such a deadlock clearly.

    I've been surprised that you haven't already seen them while eating memory
    such that filesystems come into play. Perhaps you guys only use swap
    partitions, and something like a swapfile with some memory pressure might
    trigger this? Or it could be a side effect of one of the other changes.

    Nigel

    > Greetings,
    > Rafael

    --
    See our web page for Howtos, FAQs, the Wiki and mailing list info.
    http://www.suspend2.net IRC: #suspend2 on Freenode
    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2006-02-04 12:14    [W:0.026 / U:122.068 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site