On Wed, 20 Feb 2013, Eric W. Biederman wrote: > > Oh, okay. But it's no different from any other filesystem in that > > respect. Processes generally can't be frozen while they are waiting > > for filesystem I/O to complete. In many cases they can't receive > > signals either (they are in an uninterruptible wait state). > > Ick. So the process freezer and all network filesystems has problems? > Especially nfs?
I don't know any of the details. On the other hand, it is not exactly hot, up-to-the-minute news to learn that NFS has problems... > > There's a big difference between preemption and freezing: Preemption > > is involuntary whereas freezing is voluntary. It's like the difference > > between preemptive and cooperative multitasking. > > I hadn't realized freezing was voluntary. That certainly seems like a > pain. More precisely, it's voluntary when processes are running in kernel mode. When they're in user mode there is no problem; they get sent a signal and then go into the freezer when they switch to kernel mode to process the signal. > >> At most I would suggest that processes be frozen in reverse priority > >> order. Which unless there is a priority inversion should solve this > >> problem without an additional proc file. > > > > Do fuse daemons (and the processes they rely upon) run with elevated > > priority? > > I don't know if the daemons are of an elevated scheduling priority today > but if they aren't it is as easy to require an elevated scheduling > priority as it is to require a magic freezer priority. Furthermore if > they don't run at an elevated priority there is the possibility of > priority inversion. This seems like a reasonable thing to try out. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
