Testing the performance impact of kernel modifications

[valdis.kletnieks at vt.edu]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 486 bytes
Desc: not available
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20181015/c5de68dd/attachment.sig>