3 ms·
This isn't a bad idea. However, assuming heterogenous hardware(CPUs, GPUs, RAM, Network, capabilities) the OS problem is primarily a driver problem. Resource ma
by random3 2y ago
This isn't a bad idea. However, assuming heterogenous hardware(CPUs, GPUs, RAM, Network, capabilities) the OS problem is primarily a driver problem. Resource management seem like a candidate for a microkernel and this can expose a relational interface to a distributed OS. The distributed OS is primarily a resource manager and well fit for a similar relational interface.
Provided that, besides drivers, the state management (tasks) is a relatively big issue, this makes the whole setup not far from a DB architecture and most managers/schedulers are arguably easily generalizable to a relational interface. In fact most distributed systems run on some form of distributed state management / DB (e.g. Raft, Zookeeper)
This said, I think the more granular approach for the kernel is maybe a cleaner way to think about it. Also, any pragmatic approach would need to take drivers into account and I wonder if it's realistic to assume anything else but major kernels.
- rwmj 2y agoAs they seem to be targeting only cloud, the set of drivers you actually need to implement is relatively small. eg. Plenty of "toy" OSes get away with implementing just a few virtio drivers and hence can run on qemu, KVM, and AWS, which is enough for them.
- random3 2y agofair enough, but wouldn't a virtualization layer in between defeat the purpose?
- rwmj 2y agoI'm not quite sure what you mean, but if you target the cloud as the platform (as is stated in the article), then you always have a virtualization layer, even if you provision on something like AWS Bare Metal Instances. (The reason bare metal instances use virtualization is not obvious: It's so you don't try to reflash the firmware on devices for a persistent attack.)
- random3 2y agoI'm thinking of Amdahl's law. Any effort to disaggregate OS and kernel for performance capped by the performance of the virtualization layer (about which I know to little to get any intuition).
- rwmj 2y agoVirtualization adds a constant overhead to various I/O operations, usually reckoned to be 2-5%, and nothing to CPU bound processes since the CPU just executes userspace instructions as normal. For AWS the overhead will be less since they use a specialized partitioning hypervisor and a lot of custom hardware assistance, including paravirt I/O devices implemented directly in hardware. This small overhead is almost always a good trade-off for the convenience of virt / cloud, such as easy provisioning, live migration, hardware independence and so on. The DBOS decision to only target the cloud makes lots of sense.