Messages in this thread | | | From | (Eric W. Biederman) | Date | Tue, 28 Jul 2020 08:20:41 -0500 | Subject | Re: [RFC][PATCH] exec: Freeze the other threads during a multi-threaded exec |
| |
ebiederm@xmission.com (Eric W. Biederman) writes:
> Linus Torvalds <torvalds@linux-foundation.org> 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
| |