Messages in this thread | | | Date | Tue, 13 Jan 2004 12:49:13 +0100 | From | Pavel Machek <> | Subject | Re: 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/
| |