public inbox for [email protected]
 help / color / mirror / Atom feed
From: Olivier Langlois <[email protected]>
To: [email protected]
Subject: Kernel config settings known to be detrimental to io_uring performance?
Date: Mon, 06 Dec 2021 15:18:20 -0500	[thread overview]
Message-ID: <[email protected]> (raw)

Hi,

I am building a custom Kernel from ArchLinux standard Kernel package.

I do that mostly to get CONFIG_NO_HZ_FULL on since I dedicate cores to
RT threads of my app.

Beside that, I play it safe by not touching to settings that I have no
idea what they do and I keep the default upstream packaging settings.

There is one timing measurement that I do in my app. the time it takes
for:

1. Thread A to write in an eventfd to wake up thread B running an
io_uring event loop
2. thread B userspace event processing + write data in a TCP socket
through io_uring
3. thread B Receive the write CQE

With previous kernel settings, the timing that I had was 85 uSecs.

Idk why but yesterday, I felt more daring than usual I have decided
disable a couple of features that aren't needed. So I disabled:

CONFIG_AUDIT
CONFIG_SECURITY_APPARMOR (had to remove it to be allowed to remove
CONFIG_AUDIT)
CONFIG_HYPERVISOR_GUEST (my kernel will always only run on bare metal)
CONFIG_AMD_MEM_ENCRYPT (my server is Intel based)

and I have been amazed by how much faster io_uring became. My timing
went from 85 to 59.8 uSecs (A 30% improvement)!

Now, because I have disabled a couple of settings all at the same time,
I am not really sure which one is responsible for this amazing result
but I would suspect that CONFIG_AUDIT might be the one...

You know what? I would be willing to take a couple more of those juicy
30% improvements anytime...

So I was wondering if someone is aware of some other kernel config
settings that are notoriously detrimental to the kernel io_uring I/O
performance (more specifically TCP/IP)?

My next try will be to disable:
CONFIG_SECURITY_NETWORK
CONFIG_SECURITY_TOMOYO
CONFIG_SECURITY_SMACK

I suspect that I might not find another 30% improvment... but who
knows? if I do, I will report back

Greetings,


                 reply	other threads:[~2021-12-06 20:18 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=67933da84217368a732a4820ee97b0afe47a1beb.camel@trillion01.com \
    [email protected] \
    [email protected] \
    /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