Auditing io_uring

Posted Jun 4, 2021 9:28 UTC (Fri) by Freeaqingme (guest, #103259)
Parent article: Auditing io_uring

I'm not sure I understand where the slowdown comes from. If it's in a hot path, the code is executed a gazillion times. Shouldn't the CPU be able to optimize it away pretty quickly using branch prediction?

I realize branch prediction has been somewhat of a hassle around the kernel (and elsewhere), but I'd expect it to be quite useful in scenarios like these.

to post comments

Auditing io_uring

Posted Jun 4, 2021 12:12 UTC (Fri) by matthias (subscriber, #94967) [Link]

The CPU cannot optimize away the comparisons. The audit flag could change in the meantime. What branch prediction does, is to allow the execution to continue while the comparison is done. If the prediction is correct (which it should be almost always), you only have the impact of loading the values and doing the comparison. If the prediction is wrong, the CPU pipeline needs to be flushed (because execution continued in the wrong branch) and you loose many cycles.

It seems that the slowdown is just because of the overhead of the instructions added to the hot path. However, 5% is really quite much. Either the auditing code is not optimized that much, or the io_uring only has a few instructions on this path. This means that the "real code" only takes 20 times as much time as the auditing code that just has to verify that auditing is indeed turned off.