Earlier quoted context omitted.
It's a good thing.
What is a good thing...?
That is Martha Stewart's catch phrase.
Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
381–390 of 567 posts
Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#382Earlier quoted context omitted.
Problem is, most companies that need a lot of power only care about one thing - peak performance. And they tune it carefully in order to not overspend while guaranteeing minimal downtime. This means that they'll have to pretty much scale their infrastructure up by exactly 30%. That's a LOT for these big clients. Honestly, I'd just make sure the server firewalls are super tight and not take in the future patches. At l…
If they really care about peak performance, I don't believe the PTI patch will affect them. If you can change your system in a way that the power-hungry part does not work on untrusted data, you can not with "nopti" and ignore it. Systems which both need lots of maxed-out CPUs and traffic directly from wild internet are pretty rare. They're unlikely to run on a virtualised systems either.
Systems which both need lots of maxed-out CPUs and traffic directly from wild internet are pretty rare.
That's a good description of basically every cloud environment out there, from AWS on down.
In other words they are extremely common.
Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#383Earlier quoted context omitted.
In the future this possible on Linux with the filesystems that support DAX. Currently this all pretty experimental with lots of work being done in this space in the last two years. But this will require you to have the right kind of flash storage, right kind of fs, right kind mount options, and probably a different code path in userspace for DAX vs traditional storage. So we're a little ways away from this.
DAX doesn't appear related here at all. That is about bypassing the page cache for block devices that don't need one. That doesn't move anything from kernel land into userspace, certainly not in the app's process in userspace anyway.
If you bypass the page cache you do not have read()/write() and mmap you avoid the syscall overhead. This matters a lot for high IOPs devices. Also these new fangled devices claim support word cache line sync using normal cpu flush instructions. Also avoiding fsync syscall.
Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#384Earlier quoted context omitted.
It's a good thing CPU is fairly compressible. Unless you meter it very carefully, you'll see the performance hit and it'll not impact you that much. Very few of my physical boxes are over 70% CPU utilization on a daily average. It's, however, really bad if you sell CPU cycles for a living. You just lost between 5 and 30% of your capacity. If you have a large building, you just lost part of your parking lot to the Int…
Hmm. Since everyone that sells (Intel) CPU cycles for a living suffers the same loss of supply this boils down to pricing; the same demand chasing fewer cycles will drive up prices and the market will adapt. 30% is a big hit. I'm wondering if that isn't a bit exaggerated, or perhaps the consequence of a poorly optimized workarounds that will rapidly improve. I recall seeing figures on the order of 3% only a few days…
30% is a worst case for a workload optimized to hit the performance bug as hard as possible.
How big it will be for your workload is a function of what your workload is. Benchmark if it is important to you.
Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#385Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#386Earlier quoted context omitted.
It has very little to do with what kind of syscalls (I/O or other kinds) and all to do with how many syscalls a given application makes per given time period. Compute bound applications are already avoiding syscalls in their hotter parts. This will mostly be a blow to databases, caching servers and other such I/O limited applications.
Would it be fair to say that this might cause acceptation in the shift from on prem to the public cloud, where there are performance guarantees?
There aren't really performance guarantees for CPU and the ones that are there won't help here. When this patch is released big providers will have the same hardware as before and sell it in the same way - but the OS and userspace will just be slower for some use patterns.
There isn't a guarantee that will compensate for that any more than if you updated some piece of your software infrastructure to a new version that just got slower.
Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#387Earlier quoted context omitted.
From the merge commit: +#ifdef CONFIG_PAGE_TABLE_ISOLATION +# define DISABLE_PTI 0 +#else +# define DISABLE_PTI (1 PS - MSFT has not published relnotes, so we do not know yet. We'll find out soon enough.
I meant disable at run time, not disabling via recompiling your own kernel.
That is also in there. You can either specify "pti off" or "nopti" as a boot parameter.
+void __init pti_check_boottime_disable(void)
...
+ ret = cmdline_find_option(boot_command_line, "pti", arg, sizeof(arg));
+ if (ret > 0) {
+ if (ret == 3 && !strncmp(arg, "off", 3)) {
+ pti_print_if_insecure("disabled on command line.");
+ return;
+ }
+ if (ret == 2 && !strncmp(arg, "on", 2)) {
+ pti_print_if_secure("force enabled on command line.");
+ goto enable;
+ }
+ if (ret == 4 && !strncmp(arg, "auto", 4))
+ goto autosel;
+ }
+
+ if (cmdline_find_option_bool(boot_command_line, "nopti")) {
+ pti_print_if_insecure("disabled on command line.");
+ return;
+ }
+
+autosel:
+ if (!boot_cpu_has_bug(X86_BUG_CPU_INSECURE))
+ return;Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#388Earlier quoted context omitted.
It's a good thing CPU is fairly compressible. Unless you meter it very carefully, you'll see the performance hit and it'll not impact you that much. Very few of my physical boxes are over 70% CPU utilization on a daily average. It's, however, really bad if you sell CPU cycles for a living. You just lost between 5 and 30% of your capacity. If you have a large building, you just lost part of your parking lot to the Int…
>It's, however, really bad if you sell CPU cycles for a living. Who really sells CPU cycles? Cloud providers sell instances priced per core. So the real hit is by the customers since they have to shell out for more instances for the same amount of computing power. The hit I see is by providers of 'serverless' computing, since they charge per request and have their margins reduced.
> The hit I see is by providers of 'serverless' computing, since they charge per request and have their margins reduced.
AWS, Azure, and GCP all bill serverless with a combination of per-request fees and compute (GB-seconds), so I'd expect the entire hit to be passed on to the user since this will cause increased compute time for each request. N requests that used to average 300ms each will now be N requests that average, say, 400ms, so the per-request billing remains the same and the compute billing will increase by approximately 30%.
Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#389AMD must be pretty happy about this patch: https://lkml.org/lkml/2017/12/27/2
Not so sure about that. I am reading the merge commit, and comments are pretty interesting: --- a/arch/x86/include/asm/processor.h +++ b/arch/x86/include/asm/processor.h + * On Intel CPUs, if a SYSCALL instruction is at the highest canonical + * address, then that syscall will enter the kernel with a + * non-canonical return address, and SYSRET will explode dangerously. + * We avoid this particular problem by prevent…
I wrote that text. It's just documenting a bug that never affected Linux at all.
I'm having trouble finding a good reference right now.
Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#390Earlier quoted context omitted.
It is possible Microsoft has mitigated the issue in a way that has much lesser performance impact. Maybe they had a highly tuned feature to enable kernel page separation already coded but disabled. I won't be surprised if even the Linux implementation is tuned to the absolute limit in the coming months.
I think so too. It also seems the Linux version right now is in a "get it to work, optimize later" state.
If you know how to materially optimize it, I'm all ears.