ebiederm@xxxxxxxxxxxx (Eric W. Biederman) writes: > Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes: > >> It also makes for a possible _huge_ latency regression for execve(), >> since freezing really has never been a very low-latency operation. >> >> Other threads doing IO can now basically block execve() for a long >> long long time. > > Hmm. Potentially. The synchronization with the other threads must > happen in a multi-threaded exec in de_thread. > > So I need to look at the differences between where de_thread thread > can kill a thread and the freezer can not freeze a thread. I am hoping > that the freezer has already instrumented most of those sleeps but I > admit I have not looked yet. Alright I have looked at the freezer a bit more and I now see that the point of marking things freezable is for kernel threads rather that user space threads. I think there are 5 maybe 6 places the code sleeps reachable by userspace threads that are marked as freezable and most of those are callable from get_signal. For exec all I care about are user space threads. So it appears the freezer infrastructure adds very little. Now to see if I can find another way to divert a task into a slow path as it wakes up, so I don't need to manually wrap all of the sleeping calls. Something that plays nice with the scheduler. Eric
