Messages in this thread | | | From | Linus Torvalds <> | Date | Wed, 21 Mar 2018 11:15:32 -0700 | Subject | Re: [RFC PATCH 0/3] kernel: add support for 256-bit IO access |
| |
On Wed, Mar 21, 2018 at 12:46 AM, Ingo Molnar <mingo@kernel.org> wrote: > > So I added a bit of instrumentation and the current state of things is that on > 64-bit x86 every single task has an initialized FPU, every task has the exact > same, fully filled in xfeatures (XINUSE) value:
Bah. Your CPU is apparently some old crud that barely has AVX. Of course all those features are enabled.
> Note that this is with an AVX (128-bit) supporting CPU:
That's weak even by modern standards.
I have MPX bounds and MPX CSR on my old Skylake.
And the real worry is things like AVX-512 etc, which is exactly when things like "save and restore one ymm register" will quite likely clear the upper bits of the zmm register.
And yes, we can have some statically patched code that takes that into account, and saves the whole zmm register when AVX512 is on, but the whole *point* of the dynamic XSAVES thing is actually that Intel wants to be able enable new user-space features without having to wait for OS support. Literally. That's why and how it was designed.
And saving a couple of zmm registers is actually pretty hard. They're big. Do you want to allocate 128 bytes of stack space, preferably 64-byte aligned, for a save area? No. So now it needs to be some kind of per-thread (or maybe per-CPU, if we're willing to continue to not preempt) special save area too.
And even then, it doesn't solve the real worry of "maybe there will be odd interactions with future extensions that we don't even know of".
All this to do a 32-byte PIO access, with absolutely zero data right now on what the win is?
Yes, yes, I can find an Intel white-paper that talks about setting WC and then using xmm and ymm instructions to write a single 64-byte burst over PCIe, and I assume that is where the code and idea came from. But I don't actually see any reason why a burst of 8 regular quad-word bytes wouldn't cause a 64-byte burst write too.
So right now this is for _one_ odd rdma controller, with absolutely _zero_ performance numbers, and a very high likelihood that it does not matter in the least.
And if there are some atomicity concerns ("we need to guarantee a single atomic access for race conditions with the hardware"), they are probably bogus and misplaced anyway, since
(a) we can't guarantee that AVX2 exists in the first place
(b) we can't guarantee that %ymm register write will show up on any bus as a single write transaction anyway
So as far as I can tell, there are basically *zero* upsides, and a lot of potential downsides.
Linus
| |