On Mon, 11 Sep 2023 13:50:53 -0700 Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > And it seems like it's actually server people who want the "no > preemption" (and presumably avoid all the preempt count stuff entirely > - it's not necessarily the *preemption* that is the cost, it's the > incessant preempt count updates) I'm sure there's some overhead with the preemption itself. With the meltdown/spectre mitigations going into and out of the kernel does add some more overhead. And finishing a system call before being preempted may give some performance benefits for some micro benchmark out there. Going out on a crazy idea, I wonder if we could get the compiler to help us here. As all preempt disabled locations are static, and as for functions, they can be called with preemption enabled or disabled. Would it be possible for the compiler to mark all locations that need preemption disabled? If a function is called in a preempt disabled section and also called in a preempt enable section, it could make two versions of the function (one where preemption is disabled and one where it is enabled). Then all we would need is a look up table to know if preemption is safe or not by looking at the instruction pointer. Yes, I know this is kind of a wild idea, but I do believe it is possible. The compiler wouldn't need to know of the concept of "preemption" just a "make this location special, and keep functions called by that location special and duplicate them if they are are called outside of this special section". ;-) -- Steve
