The logging framework isn't a bottleneck, and other lies your laptop tells you

Re:The logging framework isn't a bottleneck, and other lies ... by derefr on Thursday May 14, 2020 @03:06AM (#23176353)

Sounds like we might need to go back to the kind of mainframe architecture that has IO offload. Split the PCIe bus into NUMA-like zones; give each zone its own (probably ARM) CPU, running its own kernel; then use "application processors" (probably x86) to command-and-control the IO zones, allocating e.g. IOMMU-subvirtualized ethernet channels to them. Control plane/data plane separation.

[ Parent | on HN ]

Re:The logging framework isn't a bottleneck, and other lies ... by magicalhippo on Thursday May 14, 2020 @09:04AM (#23178966)

There's some (to me) interesting work in this area. See for example this talk[1], where they show how a RISC-V CPU with a narrow and slow PCIe link can orchestrate the direct transfer of data between two PCIe devices (say NVME and Ethernet card), saturating the x16 link between them.

[1]: https://www.youtube.com/watch?v=LDOlqgUZtHE (Accelerating Computational Storage Over NVMe with RISC V)

[ Parent | on HN ]

Re:The logging framework isn't a bottleneck, and other lies ... by pg-gadfly on Thursday May 14, 2020 @05:04AM (#23177213)

A bunch of less powerful servers with expansion cards over a network should be much easier to manage and horizontally scalable

[ Parent | on HN ]

Re:The logging framework isn't a bottleneck, and other lies ... by simcop2387 on Friday May 15, 2020 @01:50PM (#23195074)

sort of, the network part of that ends up being a huge bottleneck then too, with 16 drives at 5GB/s (max i've seen so far) each you've got 80GB/s you need for the network to each server. You start getting into the really expensive side of things speed wise.

[ Parent | on HN ]