Another Look At The Performance Impact To IBM's POWER9 L1d Flushing Change

[phoronix]

Phoronix: Another Look At The Performance Impact To IBM's POWER9 L1d Flushing Change

Last week I provided some benchmarks looking at the IBM POWER9 mitigation for the L1 data cache needing to be flushed upon entering the kernel and on user accesses due to a recently disclosed vulnerability. POWER9 allows speculatively operating on validated data in the L1 cache, but when it comes to incompletely validated data paired with other side channels it could lead to local users potentially obtaining improper access to data in the L1 data cache. When benchmarking the impact on a POWER9 4c/16t CPU the overall impact was fairly modest while since then I fired up some benchmarks as well on a large POWER9 server with 44 cores / 176 threads to see the performance impact of this default Linux kernel change.

http://www.phoronix.com/vr.php?view=29759

[kgardas]

Michael,

you wrote:

"This change did have a significant impact on the MariaDB and PostgreSQL database server performance. This was a much larger impact than what was seen on the smaller 4-core POWER9 system while also having different storage, etc."

but the problem is that you are comparing apples with oranges here. E.g.

P9 - 4c/16t you tested: Client 50 mode read-only: https://www.phoronix.com/scan.php?pa...1d-flush&num=3

while today you tested: Client 50 mode read-write. And this is really a big difference! So please get your notes together and compare only apples to apples and oranges to oranges and do not confuse your reader.

Much appreciated!

Thanks,
Karel

[hiryu]

Hopefully some of the performance hit for DB's can be optimized... ~50% loss for databases is pretty ridiculous.

[skeevy420]

Pages 2 & 4: Eh, not bad.

Page 3:

[tygrus]

Is this mitigation affecting locks & thread synchronisation more?

[zxy_thf]

Is this mitigation affecting locks & thread synchronisation more?

The performance impacts are mainly from entering/leaving kernel space, so futex-based locks and synchronization should be fine (unless the code frequently creates/destroys locks).

I'm curious if io_uring can be employed to improve the database performance, since most of the time an io_uring based module is not supposed to perform system calls.