Testing Intel FSGSBASE Patches For Helping Elevate Linux Performance

[phuclv]

You mentioned in one of your other articles that the work on FSGSBASE had attracted interest from Microsoft, which I take to mean that they haven't already implemented it:

https://www.phoronix.com/scan.php?pa...-Linux-Patches

nope. Windows has supported FSGSBASE since Windows 8.1. The fact that MS pushes some changes for Linux's FSGSBASE support has nothing to do with Windows support

[phuclv]

One thing I haven't seen is whether Windows already handles FSGSBASE?

Windows has supported FSGSBASE since Windows 8.1. You can see the _readfsbase*/_readgsbase_*/_writefsbase*/_writegsbase* functions in the intrinsic list of VS 2015

[hotaru]

It clearly was enabled if you knew how to read the flags that were posted on the first page of the article.

it clearly wasn't. full mitigation means spectre_v2=on spec_store_bypass_disable=on l1tf=full,force, as well as compiling the entire system with LVI mitigations. none of that "conditional" or "via prctl and seccomp" shit.

[arQon]

You're nearly ALWAYS "just 1 or 2 registers short" in every loop, no matter how many registers you have. :P And the same is even more true for a compiler.

AFAICT, this is all just the KERNEL impact of freeing up those registers, isn't it? So while that's one part of the equation, and clearly of remarkable value on that side alone just from save/restore impact (substantially more than I would have expected, which makes me wonder if I haven't misunderstood things) the other side is rebuilding the userspace with the knowledge that it has 2 more registers available. Or is that already included in these benchmarks after all and I just missed where Michael noted it?

[Volta]

The last of your PostgreSQL Windows vs Linux comparison I can find is not really supporting that generality;



even though that's from 2018 and a single threaded buffer test...

It clearly shows windows doesn't sync its data. It's useless.

[Volta]

It clearly was enabled if you knew how to read the flags that were posted on the first page of the article.

There's no mention of lvi mitigation.

[Space Heater]

The last of your PostgreSQL Windows vs Linux comparison I can find is not really supporting that generality;
even though that's from 2018 and a single threaded buffer test...

Those benchmark results look insane, and I would take them with a huge grain of salt. I'm not saying Windows can't be faster, but it really makes zero sense to see a client SKU be ~2x faster than the nearly identical server SKU, and ~5x faster than most every Linux distribution.

If those benchmarks did reflect real world postgres performance, everyone would immediately jump to Windows 10 Pro for all of their database needs. A windows client license would be an insignificant price to pay for a 500% performance increase.

[elatllat]

Yes and no, Windows database servers like PostgreSQL perform much slower in general due to NTFS and the like, so there isn't any good relative 'base' value to compare it to.

The last of your PostgreSQL Windows vs Linux comparison I can find is not really supporting that generality;



even though that's from 2018 and a single threaded buffer test...

[Michael]

With postgres having an 80% difference, one may be able to deduce by simply benchmarking postgres on Windows.

Yes and no, Windows database servers like PostgreSQL perform much slower in general due to NTFS and the like, so there isn't any good relative 'base' value to compare it to.

[elatllat]

One thing I haven't seen is whether Windows already handles FSGSBASE?

With postgres having an 80% difference, one may be able to deduce by simply benchmarking postgres on Windows.