<div dir="ltr">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. I am curious how you would best measure the impact of similar modifications (since obviously one isn't always in the kernel code when executing a process). My interest is in testing different approaches of making pointer runtime checks.<div><br></div><div>My theory would be that perhaps writing some test code that exercises different extremes (calling the syscall api continually to do a range of tasks) to see how much slower the code would be between the safer version and the old version. This however might not reflect real world performance for I/O (sockets) such as web servers that spend less time in the kernel. I have seen a paper that benchmarked kvm against xen server 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.</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Oct 16, 2018 at 1:08 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 Mon, 15 Oct 2018 23:42:03 +0800, Carter Cheng said:<br>
<br>
> I was wondering what are some good ways to assess the performance impact of<br>
> kernel modifications. Are there some papers in the literature where this is<br>
> done? Does one need to differentiate between CPU bound and different types<br>
> of I/O bound processes etc?<br>
<br>
That is *so* totally dependent on exactly what the modification is, that<br>
there's no right answer here.<br>
<br>
The things you will want to measure for a new TCP flow control module (to<br>
measure the difference between, say, cubic and new_reno and fq_codel and<br>
your new module) will be *totally* different from changes to an LSM, which again<br>
will be different from an overhaul of a disk I/O scheduler.<br>
<br>
And then, the environment matters as well.  The performance metrics that I care<br>
about on my laptop (which is used as a desktop replacement) are "can I do a<br>
kernel build and my desktop environment still work well" type things.  But the<br>
numbers I care about on the machines I maintain across the hall in the data<br>
center are different - those are disk storage, backup, and archive - so I'm<br>
willing to burn a lot of CPU in both kernel and userspace if it gets me more<br>
IOPs and throughput - important when you have 500+ million files in a single<br>
petabyte-plus file system.  Meanwhile, the guys a few cubicles down are doing<br>
HPC, which means they want as little kernel CPU usage as possible because that<br>
gets in the way of user computations.<br>
<br>
And sometimes, it doesn't matter in the slightest what the performance impact is,<br>
because the change is required for correctness - running incorrect code faster is<br>
still running incorrect code.  See the recent Spectre patches for an example.<br>
<br>
<br>
</blockquote></div>