No reasonable person has ever argued that a consumer buying a (digital) copy of a game obtains the exclusive rights to the game. This is such a cheap embarrassingly stupid attempt to come up with a straw man.
I'll listen to Sony management and lawyers whining about copyright after they paid the damages and fines and get out of jail for every rootkit they deployed. Should be any century now.
A CDN *cache* server is a special case. Netflix cache appliances can accept the risk of running FreeBSD -CURRENT and upgrading half their fleet to the latest snapshot every ~2 weeks and we thank them for battle testing FreeBSD's active development branch in production. It really helps to reveal regressions (both correctness and performance) early in the subsystems and drivers that matter to their usecase.
Most users will neither be willing nor able to accept the trade-offs that Netflix chose.
You're just wrong. FreeBSD stable branches are the development branches from which new minor releases (with a stable ABI) are forked. If you want to be pedantic you want to follow the releng branches for most production deployments (release + security and non-security errata patches). Unless you build from source yourself you the tools (pkgbase, freebsd-update) don't make that distinction visible to the user.
The ARM v7M architecture helps a lot here because the NVIC supports priority inheritance without disabling interrupts. Yes you have to assign your priorities correctly and yield CPU time for anything compute bound, but again the architecture helps you in the form of the SVCall+PendSV exception pair. The PendSV handler can easily be multiplexed on the Cortex-M3/M4 using atomic operations on bit-banded memory. I've needed only a few dozen lines of Forth to set this up on bare metal without an RTOS to split peripheral drivers in a short interrupt handler saving the required state and delegating protocol handling to a lower priority callback.
A 1GHz superscalar Cortex-M7 can still hit a 12 cycle interrupt latency if the system stack is kept in the 2x32 bit wide zero cycle dTCM, and the VTOR and handler are in the iTCM thanks to lots of bandwidth and a reasonably short pipeline. The NVIC is truly the underappreciated superpower of the Cortex-M family. You can implement a full RTOS or complex bare metal application without ever having to disable interrupts. On other MCU architectures (most RISC-V, PIC32, even older crap refusing to die) you'll easily end up with closer to 100 then 10 cycles of jitter from critical sections having to run with disabled interrupts e.g. context switching code.
That’s fair. I’m not saying x86 is a pig for interrupt latency. But M still isn’t a fair comparison. X86 runs general purpose OSes which like to do things like load balance interrupts (not that I’m convinced this is actually a good design) which NVIC doesn’t have a full solution to especially for multicore (A series also uses a GIC).
The other problem is that A series and x86 runs out of DRAM typically whereas M is generally set up to run its ISRs out of SRAM so it can actually realistically hit its low latencies. But even though A also has significantly better nominal interrupt latency (competitive with M actually), in practice it’s similar to x86 because DRAM dominates anyway. Also of course best case latencies are when you don’t use the FPU which is more common on M series than it would be on A or x86 (and x86 also has generally more SIMD stuff to handle)
One advantage they have for building larger systems is that they allow you to crack stores into two parts. The part that has to retire in order for the local CPU and the write back to memory. Now assume you have multiple banks of memory and one of them stalls. A system with TSO can't allow the other banks to make progress because that would make the stores visible to other CPUs (or peripherals) out of program order. So you have to stall stores to otherwise ready memory banks and hold on to valuable ROB and store queue resources for longer.
I'll listen to Sony management and lawyers whining about copyright after they paid the damages and fines and get out of jail for every rootkit they deployed. Should be any century now.
reply