Re: [ 00/10] [Suspend2] Modules support.

[Nigel Cunningham <nigel@suspend2.net>]

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

Attachment: pgp6onCcTMNlb.pgp
Description: PGP signature