On Tue, 16 Oct 2018 01:23:45 +0800, Carter Cheng said:
I am actually looking at some changes that litter the kernel with short code snippets and thus according to papers i have read can result in CPU hits of around 48% when applied is userspace.
You're going to need to be more specific. Note that 48% increase in a micro-benchmark doesn't necessarily translate to a measurable performance change - for example, I have a kernel build running right now with a cold file cache, and it's only using 6-8% of the CPU in kernel mode (the rest being gcc in userspace and waiting for the spinning-oxide disk). If the entire kernel slowed down by 50% that would only be 3-4% change visible at the macro level.
but I haven't seen any kernel space papers measuring degradations in overall system performance when adding safety checks(perhaps redundant sometimes) into the kernel
Well.. here's the thing. Papers are usually written by academics and trade journal pundits, not people who write code for a living. As a result, they end up comparing released code versions. As a worked example, see how the whole Spectre thing turned out - the *initial* fears were that we'd see a huge performance drop. But the patches that finally shipped for the Linux kernel were after a bunch of clever people had thought about it and come up with less intrusive ways to close the security issue. (Having said that, the guys at Phoronix do a reasonable job of doing macro-level benchmarks of each kernel release and pointing out if there's a big hit in a subsystem). And as I said earlier - sometimes it doesn't matter, because correctness trumps performance.