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