5 ms·
Different instruction sets are not too bad. Copy from my comment elsewhere. > The OS can install an illegal-opcode exception handler. When a process is first
by ww520 6y ago
Different instruction sets are not too bad. Copy from my comment elsewhere.
> The OS can install an illegal-opcode exception handler. When a process is first run on the small CPU, the unsupported opcode will raise the exception. The exception handler can simply set the processor affinity of the process to the main CPU and put it to sleep. The OS will handle it like it normally would - putting the process in the run queue of the affined processor.
- saagarjha 6y agoThat sounds really slow.
- ahupp 6y agoIt only has to happen once.
- wtallis 6y agoOnce per process. I doubt operating systems will start modifying executables and libraries on-disk to tag them as using relevant instruction set extensions. And generally speaking, when an application first starts issuing SIMD instructions, that's probably not the a great time to be interrupting it even if it only needs to happen once.
- loeg 6y agoYou could imagine it as an ELF note of some kind. It's not a direction I've love to go in, and catching illegal exception traps seems fast enough that the more complicated design doesn't seem worthwhile.
- gpderetta 6y agoonce per process is perfectly fine. the issue is that once you have an active process using a feature only available on the larger cores, you can't shut off the larger cores to save power without paying a large latency to wake up that process.
- saagarjha 6y agoWell, once when it's about to try to wring maximum performance out of the processor, and if you only do it once you're ensured that your smaller cores never get used…
- chrisseaton 6y agoA single trap? That's not slow.
- saagarjha 6y agoOh, I thought the suggestion was to trap to the large core every time an unsupported instruction was executed and let the process drift back to the smaller one later. Which would be slow I would assume. If you never switched back, wouldn't any process using advanced vectorized instructions (like anything using a decent libc) be permanently pinned to the large core?
- chrisseaton 6y ago> Oh, I thought the suggestion was to trap to the large core every time an unsupported instruction was executed and let the process drift back to the smaller one later. Yes that's the idea. > Which would be slow I would assume. How expensive do you think a trap is? It takes about the order of 10 billionths of a second. > If you never switched back, wouldn't any process using advanced vectorized instructions (like anything using a decent libc) be permanently pinned to the large core? I think you can switch back next time you schedule.
- saagarjha 6y ago> I think you can switch back next time you schedule. Ok, yes, then we're on the same page. I would still think that would be slow? You'd need a full transition-to-kernel and context switch before you could execute again, which AFAIK would take at least microseconds…unless you think there would be a faster path to resume execution?
- chrisseaton 6y ago> which AFAIK would take at least microseconds… No that's around 30 ns on modern hardware I believe.
- gpderetta 6y ago
- stefan_ 6y agoThere are processor architectures (MIPS) that can't do unaligned memory access where Linux will catch the fault, emulate the memory access in kernel and return to the program. On every unaligned access. At least this only has to be done once, and frankly these AVX instructions are slow initially anyway.
- loeg 6y agoAnd MIPS is slow as a dog, in part as a result of software handlers like this (software handles TLB and virtual memory walks, too, IIRC).
- saagarjha 6y agoYeah, and that was suuuper slow and everyone told you to not do it for exactly that reason…
- zokier 6y agoAs it happens, MIPS is also practically dead as an general purpose architecture...
- sigotirandolas 6y agoIt also happens on 32-bit ARM, which is maybe on its way out, but still way more common.
- gumby 6y ago
- ww520 6y agoIt only needs to be done once at the process launch. Once the processor affinity is set, it will stick to the main CPU at full speed for the entirety of the process lifetime.
- chrisseaton 6y agoWhat if the same bytes are valid instructions on both but do different things?
- saagarjha 6y agoI don't really think that's a thing on Intel? Instructions that are unsupported generally noop or do something slowly. (Or trap.)
- chrisseaton 6y agoI thought the two cores had two different ISAs?
- saagarjha 6y agoNo idea. I'm just responding on the assumption that it's just two Intel architectures, one with fewer extensions.
- gpderetta 6y agothey support different subsets [1] of the same x86-64 ISA, so opcodes won't be reused. [1] well, I hope the larger cores support a superset of the smaller cores, otherwise it would really be insane.
- loeg 6y agoUnless one of those things is "trap," that's just a horribly byzantine heterogeneous compute design that no general purpose OS will target.
- CountSessine 6y agoWhat if my program has like 1 avx2 instruction? Then we still wake up the big core and run my process there? And keep running it there? Or do we try to migrate back to the little core every once in a while? And then go back to the big core when we trap again?
- saagarjha 6y agoIt's not quite relevant to your point, but generally you wouldn't want to have one AVX2 instruction as they are only really useful if you have a bunch of data.
- deleted 6y ago[deleted]
- ww520 6y agoYes, even if the process has 1 avx2 instruction, it will be scheduled to run on the main CPU. I mean you could switch the process back to the small CPU when you detect a long stretch of opcode without the avx2 instruction, but the constant switching between the main CPU and small CPU probably is not good for performance.
- pocak 6y agoThread migration only costs on the order of 100 microseconds, including the effect of cold caches. If you keep the AVX thread on the big core for at least 100 milliseconds at a time, you only lose ~0.2% performance.
- ww520 6y agoGood to know the switching cost is low. Runtime profiling would be key to provide insight into when to switch back.
- pocak 6y agoMigrate back to the little core if the thread hasn't used AVX in a while. Linux already tracks how long ago a task used AVX-512. I assume the same mechanism could be used to track AVX as well. https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?h=x86/fpu&id=2f7726f955572e587d5f50fbe9b2deed5334bd90 https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/...