History

rseq: Switch to fast path processing on exit to user

Now that all bits and pieces are in place, hook the RSEQ handling fast path function into exit_to_user_mode_prepare() after the TIF work bits have been handled. If case of fast path failure, TIF_NOTIFY_RESUME has been raised and the caller needs to take another turn through the TIF handling slow path. This only works for architectures which use the generic entry code. Architectures who still have their own incomplete hacks are not supported and won't be. This results in the following improvements: Kernel build Before After Reduction exit to user 80692981 80514451 signal checks: 32581 121 99% slowpath runs: 1201408 1.49% 198 0.00% 100% fastpath runs: 675941 0.84% N/A id updates: 1233989 1.53% 50541 0.06% 96% cs checks: 1125366 1.39% 0 0.00% 100% cs cleared: 1125366 100% 0 100% cs fixup: 0 0% 0 RSEQ selftests Before After Reduction exit to user: 386281778 387373750 signal checks: 35661203 0 100% slowpath runs: 140542396 36.38% 100 0.00% 100% fastpath runs: 9509789 2.51% N/A id updates: 176203599 45.62% 9087994 2.35% 95% cs checks: 175587856 45.46% 4728394 1.22% 98% cs cleared: 172359544 98.16% 1319307 27.90% 99% cs fixup: 3228312 1.84% 3409087 72.10% The 'cs cleared' and 'cs fixup' percentages are not relative to the exit to user invocations, they are relative to the actual 'cs check' invocations. While some of this could have been avoided in the original code, like the obvious clearing of CS when it's already clear, the main problem of going through TIF_NOTIFY_RESUME cannot be solved. In some workloads the RSEQ notify handler is invoked more than once before going out to user space. Doing this once when everything has stabilized is the only solution to avoid this. The initial attempt to completely decouple it from the TIF work turned out to be suboptimal for workloads, which do a lot of quick and short system calls. Even if the fast path decision is only 4 instructions (including a conditional branch), this adds up quickly and becomes measurable when the rate for actually having to handle rseq is in the low single digit percentage range of user/kernel transitions.

Thomas Gleixner committed 1 year ago

Commit 3db6b381 parent 05b44ae6 files · +41 −22Browse files

Showing the changes to kernel/rseq.c (1 of 6 files). Show all

Unified · Split

kernel/rseq.c+6−2
@@ -237,7 +237,11 @@ efault: · 236 unmodified lines
237237
238238 static void rseq_slowpath_update_usr(struct pt_regs *regs)
239239 {
240− /* Preserve rseq state and user_irq state for exit to user */
240+ /*
241+ * Preserve rseq state and user_irq state. The generic entry code
242+ * clears user_irq on the way out, the non-generic entry
243+ * architectures are not having user_irq.
244+ */
241245 const struct rseq_event evt_mask = { .has_rseq = true, .user_irq = true, };
242246 struct task_struct *t = current;
243247 struct rseq_ids ids;
@@ -289,7 +293,7 @@ static void rseq_slowpath_update_usr(struct pt_regs *regs) · 45 unmodified lines
289293 }
290294 }
291295
292−void __rseq_handle_notify_resume(struct pt_regs *regs)
296+void __rseq_handle_slowpath(struct pt_regs *regs)
293297 {
294298 /*
295299 * If invoked from hypervisors before entering the guest via