Re: swsusp patch..

[Pavel Machek]

Hi!

> Hi. Here's the first reply I sent to Patrick.

[Sorry for long delay; cc-ing patrick and l-k so that this discussion
is archived somewhere; hope you don't mind.]

> Secondly, regarding the freezer hooks, they're the result of a long
> period of working on the problem. You see, the freezer in your tree at
> the moment isn't robust. If you try to initiate a suspend at the wrong
> time, particularly where there's heavy I/O, it will sometimes deadlock
> (particularly in journalling filesystem code if I remember correctly -
> it's been a while since I had the problem) or at least take a long time
> (try initiating a suspend during dd if=/dev/zero of=testfile bs=4096
> count=100000). Another problem is that you will be writing dirty data to
> swap. This freezer implementation overcomes those issues. It
> provides a

Well, writing dirty data to swap does not look like too bad
problem. If it simplifies things, I'm happy with dirty data in swap.

> of others. (Remember that in my version, I use activelist & inactivelist
> pages for the atomic copy of the rest of the data as well as any free
> memory, thereby overcoming the half-of-memory limitation). If
> someone

...introducing another "half-of-kernelmemory" limitation. [Did you see
people hitting half-of-memory problem in practice?].

How is it possible that copying into activelist & inactivelist helps?
If memorymanagment is working correctly then those lists should be
empty...

I know you are not freeing memory agresively.. But perhaps you have
exactly same "half-of-memory" problem as 2.6.0-test9 implementation
has?

> comes up with a better way to do this, I'll be more than happy to
> listen, as always. I've spent a long time looking at the issue though,
> and doubt that will happen. I'm sure the macros could be made to look
> nicer or perhaps written in assembly to improve speed, but I can't see

No assembly, please. Nicer macros would be welcome, through. No macros
would be best ;-).

Deadlocks... any user process stopped with sigstop should not block
anything in-kernel, right? That means that perhaps we need to be more
clever about kernel threads, but we should be able to get away without
hooks in paths such as "sys_read()". If killall -SIGSTOP can stop the
processes safely without additional hooks, we should be able to do
that, too...

								Pavel

-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/