lkml.org 
[lkml]   [2004]   [Jan]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Is this too ugly to merge?
Hi!

> I'm wanting to the opinion, if I may, of more experienced people
> regarding changes I have implemented in my version of Software Suspend,
> which I want to merge with Patrick and Pavel. Since I'm don't expect
> that you're all familiar with how my version works, I'll give a fair bit
> of background before I come to the question.
>
> One of the problems I ran into in developing the code was the issue of
> getting activity stopped so that (1) locks which are required in writing
> the image aren't still held, (2) we can ensure that dirty buffers are
> synced to disk and (3) freezing doesn't fail because of races between
> processes entering the freezer. Point three is especially important.
> With the implementation in the kernel at the moment, deadlocks can
> easily happen under load. (I could provide examples but I'm sure you can
> imagine).
>
> To get around these problems, I tried a number of different approaches.
> In the end, the one that has worked best has been to add hooks to the
> entrance and exit for critical paths in the kernel, and maintain a count
> of the number processes in those sections. There are also hooks to
> temporarily decrement the counter at points where a thread can block in
> kernel code, in cases where it can safely sit there until resume time.
>
> These hooks also provide a means whereby processes that want to begin
> work on a critical path can be held until post-resume.
>
> Finally, processes can be marked as needed for syncing ('syncthreads'),
> and allowed to continue through these hooks where 'normal' threads would
> be held.
>
> When we want to freeze activity, then, it is simply a matter of toggling
> a flag and waiting for the number of active processes to reduce to zero.
> During this time, user space threads that want to start new activity are
> frozen (via the hook at the start of the critical path they try to
> enter) until post suspend. Threads already in critical sections run
> until they exit the critical path or pause at one of the 'safe points',
> and syncthreads such as kjournald run normally.

Okay, I can now remember (and agree to) that we need to suspend
userspace first, and only then suspend kernelspace. Bug I don't see
why we can't suspend userspace using old, SIGSTOP-like, method.

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@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: 2005-03-22 14:00    [W:0.052 / U:1.300 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site