Messages in this thread | | | Date | Thu, 14 Feb 2013 11:41:16 +0100 | Subject | Re: Getting rid of freezer for suspend [was Re: [fuse-devel] [PATCH] fuse: make fuse daemon frozen along with kernel threads] | From | Miklos Szeredi <> |
| |
On Wed, Feb 13, 2013 at 10:21 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > On Wednesday, February 13, 2013 06:34:16 PM Miklos Szeredi wrote:
>> >> So I think the PF_FREEZE_DAEMON idea (the patch from Li Fei that >> started this thread) may still be our best bet at handling this >> situation. The idea being that pure "originator" processes (ones that >> take no part in serving filesystem syscalls) can be frozen up-front. >> Then the "fuse daemon" (or "server") processes are hopefully in a >> quiescent state and can be frozen without difficulty. >> >> Unfortunately it needs help from userspace: the kernel can't easily >> guess which processes are part of a "fuse daemon" and which aren't. >> Fortunately we have a standard library (libfuse) that can tell it to >> the kernel for the vast majority of cases. > > So basically the idea would be to introduce something like PF_FREEZE_LATE > for user space processes that need to be frozen after all of the other > (non-PF_FREEZE_LATE) user space processes have been frozen and hack fuse > to use that flag?
Yes.
It is essentially the same mechanism that is used to delay the freezing of kernel threads after userspace tasks have been frozen. Except it's a lot more difficult to determine which userspace tasks need to be suspended late and which aren't.
Thanks, Miklos
| |