Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions [pdf]

penberg.org

Post reply on HN
Print view View original

131–140 of 291 posts

Re: I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions [pdf]

#131

Post by the_af »

thaumaturgy wrote: post #52
bluetomcat wrote: post #42

We need entirely new OS abstractions to replace the dated notions of hierarchical file systems built around the metaphor of file cabinets, I/O as streams of bytes, terminals, process hierarchy. Essentially, say goodbye to the Unix model after 50 years. It would open up an entirely new world of software experimentation and craftsmanship.

I would like to see an updated file system architecture that's closer to a database, with tagging and all that. And I could see that extending to processes too. But what are you imagining as alternatives for i/o and terminals?

Wasn't this kind of filesystem an abandoned plan for one of the (now old) versions of Windows? Like Windows 2000 or XP? I don't remember why they ditched this plan. Maybe it wasn't such a good idea after all, who knows.

Re: I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions [pdf]

#132

Post by dorlaor »

bluetomcat wrote: post #42

We need entirely new OS abstractions to replace the dated notions of hierarchical file systems built around the metaphor of file cabinets, I/O as streams of bytes, terminals, process hierarchy. Essentially, say goodbye to the Unix model after 50 years. It would open up an entirely new world of software experimentation and craftsmanship.

At Scylla we initially defined a new filesystem which adheres shard-per-core and thus a single physical hyperthread has the sole access to the data and thus there is no contention.

While it will be better than current XFS, we've made aio improvement to the later over the years and today it's good enough for ScyllaDB.

Practically, even though Scylla has its tcp/ip stack in userspace on top of DPDK, we learned over the years that it's ok to use the less efficient kernel tcp stack. Most of the overhead and the optimizations can still happen within the DB itself as long as it controls the memory, the cache and manages the networking queues

Re: I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions [pdf]

#133

Post by wongarsu »

bluetomcat wrote: post #70
thaumaturgy wrote: post #52

Earlier quoted context omitted.

I would like to see an updated file system architecture that's closer to a database, with tagging and all that. And I could see that extending to processes too. But what are you imagining as alternatives for i/o and terminals?

What if we surpass file systems completely? Imagine every process having its own "non-volatile" memory area, where all persistent state is kept between restarts, with a clean OS interface to share that state to other processes? Terminals and process hierarchy are a complete no-go in a fresh design. Every entity in the system can be identified through unique IDs which can be handed down to other processes based on dif…

Currently my mother has a Pictures folder which contains her pictures, where she can open them with the default photo viewer, with an editing program, and where she can trivially add files or make backups with the Windows Explorer. Any alternative interface I can imagine that offers the same flexibilty of using the same picture in multiple programs just ends up mimicking files.

There's room to replace traditional folder structures with paths or anything else, and most traditional file system implementations have really slow search. But I don't see a future in replacing the notion of a file, it maps too well to the intentions of the user.

Re: I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions [pdf]

#134

Post by gmueckl »

inetknght wrote: post #114

Look to GPUs for better solutions: make more discrete -- less functional overall but higher performance -- cores, and move them closer to the data; then let the CPU just handle coordination of the discrete processors. Think of SIMD but on a massive scale. Think of blocks of RAM with math processors. Or the same in your NVMe/NIC/etc.

HP announced their ambition to do that a few years ago, framing it as a grand vision of the future of computing. I haven't heard anything since. This kind of offloading or distributed computing isn't quite a new idea, but it hasn't materialized yet. I suspect that it is too tough a nut to crack for the general case.

Re: I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions [pdf]

#135

Post by the_af »

dllthomas wrote: post #83
jaas wrote: post #51

Earlier quoted context omitted.

"Unix was never a good design" Nothing's perfect. Unix was a great design that served its purpose well for a long time, and evolved a bit along the way. Saying it was "never good" is trivializing and, in my opinion, arrogant.

There were always objections. "Unix went from being the worst operating system available, to being the best operating system available, without getting appreciably better." https://news.ycombinator.com/item?id=19416485 Which isn't to say that those POV were necessarily correct, just that it isn't all hindsight.

To be fair, there are always objections to any working piece of technology.

It's not helpful to claim "it was never good design". It was a working design that drove technology to the point it is now, and in that sense it was hugely successful. What kind of perfect and pure tech do some people want, anyway? Pick anything, whatever they like -- say, Plan 9 or OS/2 or whatever -- and I can bet you in a parallel universe where that tech won, someone on para-HN will claim that it sucked and it was never a good design and if only Unix had won.

Re: I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions [pdf]

#137

Post by the8472 »

loeg wrote: post #115
the8472 wrote: post #18

Don't kTLS sockets[0] with crypto offloading[1], sendfile/vmsplice, device-to-device DMA transfers[2] and possibly io_uring solve all those things on linux? Granted, they're not POSIX, but they're incremental extensions. Netflix implemented similar extensions in freebsd[3] [0] https://www.kernel.org/doc/Documentation/networking/tls.txt [1] https://lwn.net/Articles/734030/ [2] https://lwn.net/Articles/767281/ [3] http…

Not really. These are all incremental performance improvements on POSIX but don't address the author's concerns / desires in the paper. All of them continue to require the kernel to mediate IO between userspace and the hardware. For some reason the author is fixated on direct user access to partitioned hardware queues. Netflix's CDN operating system is based on FreeBSD, and they did add a kind of kTLS implementation,…

The means may be different, but the ends they aim for seem to be similar. The ends here are improved latency, throughput, parallelism, non-blocking APIs and security.

The above-mentioned improvements aim to address the first four without completely bypassing the kernel, instead changing APIs so they step out of the way most of the time, limiting them to coordination tasks and then either offloading to the hardware or directly piping the data to/from userspace mappings without additional context switches where needed.

VMs using SR-IOV address the security aspect.

It's basically the difference between a green field design and tacking all those innovations onto the glueball that is linux. The latter may be ugly and complex, but it has the advantage of being backwards-compatible.

Re: I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions [pdf]

#138

Post by Khoth »

bluetomcat wrote: post #101
thaumaturgy wrote: post #88

Earlier quoted context omitted.

> Imagine every process having its own "non-volatile" memory area, where all persistent state is kept between restarts... I'll treat this seriously: as software development practices are just now beginning to mature, with more emphasis on test coverage being considered best practice, sure ... maybe. But there's still a lot of software out there for which "restart the application" (or even, "restart the stinking OS")…

> But there's still a lot of software out there for which "restart the application" (or even, "restart the stinking OS") is the only practical solution when it's behaving badly. Which, in principle, doesn't prevent a program from crashing or misbehaving when it encounters a corrupted file left over from its last run. In the imagined system, the application developer would be fully aware whether he is putting a data s…

> Why would you need to communicate with any process? Maybe I need to communicate with the currently running instance of "HTTP Server App" or "Database Engine App", not with an unrelated process my program knows nothing about.

Today, I piped the output of some process I was running into grep. Neither of these programs knew about the existence of the other.

Later, I used an image editor to create an image, then used a web browser to upload it to a website. The web browser and image editor were unaware of each other's existence.

Re: I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions [pdf]

#139

Post by wongarsu »

Ericson2314 wrote: post #45
bluetomcat wrote: post #42

We need entirely new OS abstractions to replace the dated notions of hierarchical file systems built around the metaphor of file cabinets, I/O as streams of bytes, terminals, process hierarchy. Essentially, say goodbye to the Unix model after 50 years. It would open up an entirely new world of software experimentation and craftsmanship.

Amen to that. Unix was never a good design, and now is severely out of date. We can no longer afford to hack around it.

Which is why we have Windows with the NT family of kernels. It's a reimagining that contains great ideas like a flexible file system stack that allows you to dynamically add drivers that add encryption, compression, antivirus checks etc, and a few bad ideas like a flexible file system stack that's orders of magnitude slower when working with small files than unix implementations.

Windows is a mainstream OS that is very different from Unix in many regards (even if it still has files). And it really shows that the grass isn't greener on the other side: some parts are great, some parts are terrible, but there aren't a lot of things that offer a universally better tradeoff.

Re: I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions [pdf]

#140

Post by virgilp »

acdha wrote: post #116
jchrisa wrote: post #30

Earlier quoted context omitted.

Sure. But the point of (early) NoSQL was IO optimization, not logical consistency.

I never saw it portrayed that way: it was always higher-level programmer ease of use pitches along the lines of “isn’t this easier than doing a JOIN?” pitch shortly before the speaker had a valuable learning experience about the value of data integrity and consistency.

You really don't remember the "web scale" memes about Mongo? It was always primarily about "performance".
Post reply on HN