From: valdis.kletnieks@vt.edu (valdis.kletnieks at vt.edu)
To: kernelnewbies@lists.kernelnewbies.org
Subject: Testing the performance impact of kernel modifications
Date: Mon, 15 Oct 2018 13:07:54 -0400 [thread overview]
Message-ID: <38527.1539623274@turing-police.cc.vt.edu> (raw)
In-Reply-To: <CALS6=qVpAjSUSdzW2-man=vmPGucUc-8kOxRSOgtdSjpCvRArQ@mail.gmail.com>
On Mon, 15 Oct 2018 23:42:03 +0800, Carter Cheng said:
> I was wondering what are some good ways to assess the performance impact of
> kernel modifications. Are there some papers in the literature where this is
> done? Does one need to differentiate between CPU bound and different types
> of I/O bound processes etc?
That is *so* totally dependent on exactly what the modification is, that
there's no right answer here.
The things you will want to measure for a new TCP flow control module (to
measure the difference between, say, cubic and new_reno and fq_codel and
your new module) will be *totally* different from changes to an LSM, which again
will be different from an overhaul of a disk I/O scheduler.
And then, the environment matters as well. The performance metrics that I care
about on my laptop (which is used as a desktop replacement) are "can I do a
kernel build and my desktop environment still work well" type things. But the
numbers I care about on the machines I maintain across the hall in the data
center are different - those are disk storage, backup, and archive - so I'm
willing to burn a lot of CPU in both kernel and userspace if it gets me more
IOPs and throughput - important when you have 500+ million files in a single
petabyte-plus file system. Meanwhile, the guys a few cubicles down are doing
HPC, which means they want as little kernel CPU usage as possible because that
gets in the way of user computations.
And sometimes, it doesn't matter in the slightest what the performance impact is,
because the change is required for correctness - running incorrect code faster is
still running incorrect code. See the recent Spectre patches for an example.
-------------- 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/18ddfc9c/attachment.sig>
next prev parent reply other threads:[~2018-10-15 17:07 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-15 15:42 Testing the performance impact of kernel modifications Carter Cheng
2018-10-15 17:07 ` valdis.kletnieks at vt.edu [this message]
2018-10-15 17:23 ` Carter Cheng
2018-10-15 19:19 ` valdis.kletnieks at vt.edu
2018-10-15 19:48 ` Carter Cheng
2018-10-23 13:59 ` SeyedAlireza Sanaee
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=38527.1539623274@turing-police.cc.vt.edu \
--to=valdis.kletnieks@vt.edu \
--cc=kernelnewbies@lists.kernelnewbies.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).