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

261–270 of 291 posts

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

#261

Post by drewg123 »

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 host of reasons was mostly one reason: "lack of time".

Now that we have to deal with multiple vendors of inline hardware TLS offload solutions, it is more critical to get it upstream, and so it is being upstreamed as we speak. The first piece of it (fixing send tags so they are reliable and can be used for inline hw tls in addition to hardware pacing) is up for review right now: https://reviews.freebsd.org/D20117

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

#263

Post by p_l »

Animats wrote: post #118

Mainframe designers had this problem under control by 1970. Mainframes had, and have, "channels". A channel is part of the processor architecture. It takes commands, sends them to a peripheral, and manages the data transfer in both directions. Channels have some privileged functions through which the OS tells them where the data is supposed to go in memory. The architecture of channels is well defined, and peripheral…

MCA was normal DMA bus, including extensions to use it as memory bus (which added few pins to help recognize a memory card and manage it, with plain MCA transfers for access)

Closest to complex "IO Channel Program" on PCs was I2O which largely tanked despite leaving huge mark on SCSI controller design.

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

#264

Post by p_l »

tinktank wrote: post #104
phkamp wrote: post #65

Congratulations! You have reinvented the Mainframe Channel Processor! Your next challenge: Try to avoid reinventing the 3745 Frontend Processor.

Why so negative and condescending?

While I don't like that tone, it's at times hard to not fall into it.

Because all of this had happened before and will happen again, often without learning anything about the past (example case: NoSQL)

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

#265

Post by p_l »

inetknght wrote: post #179
convolvatron wrote: post #154

Earlier quoted context omitted.

'systems code' like protocol implementations and device drivers tend to be very control-flow centric. on a simd machine in the worst case this means narrowing the 'vector length' to effectively 1. since these are throughput machines, thats often pretty bad. I do agree with you that lots of little processors is a good way forward here with a careful eye towards reducing sharing of state, but maybe its useful in this c…

I thought separate cores do have their own separate instruction streams -- sometimes even completely different architectures and/or supported instructions? Is that not the case?

No, they aren't. Generally you have some level of grouping and complex rules on how and when can they branch

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

#266

Post by jstimpfle »

pjmlp wrote: post #254
jstimpfle wrote: post #206

Earlier quoted context omitted.

Only that this doesn't even touch on design, or what parts could have been done better.

Sure it does, not using C to start with. Or in another form, C should have done the same as other systems languages, do proper bounds checking, arrays and strings without implicit decay into pointers. Second, having a proper UI story like NeXTSTEP or NeWS, and not the X11 Frankenstein.

Equating kernel design with choice of implementation is a stretch.

Also, Unix is not X11, and weren't the other ones running on top of Unices as well?

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

#267

Post by samzevo »

https://coincircle.com/l/fzxDSBPmP6 https://coincircle.com/l/Q6LtdZDEe4 https://coincircle.com/l/sfX5us6vcQ https://coincircle.com/l/HTgyczkpcY https://coincircle.com/l/UFQeBdGEjS https://coincircle.com/l/dhrwz0hfv9 https://coincircle.com/l/SNHAky12MH

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

#268

Post by gmueckl »

inetknght wrote: post #211
gmueckl wrote: post #192

Earlier quoted context omitted.

And transferring data to and from the GPU is also a source of overhead.

Despite having an overhead of transferring data to and from the GPU: it's still faster to move the data to the GPU and let the GPU process it locally than it is to leave it in main RAM away from the processing. Transferring data to and from the CPU is also a source of overhead; even your CPU has cache to bring the data more local. So what's your point?

Whatnyounsay is not true as a blanket statement: the overhead for transferring data to GPU memory is higher than accessing main memory from the CPU, so depending on what you do, the data transfer to the GPU might not result in a performance gain at all.

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

#269

Post by hyc_symas »

Unklejoe wrote: post #228
kazinator wrote: post #193

Earlier quoted context omitted.

We can't expose a DMA controller directly to programs, but an API could be devised for it. Such a thing is needed even just from the mere portability point of view: making different DMA controllers on different systems look the same. Applications will typically specify transfers using virtual addresses, but DMA controllers will understand physical memory (usually, but maybe there are virtually mapped ones out there).…

> but DMA controllers will understand physical memory Yup, this is what I’ve found on many embedded SoCs. It’s unfortunate. The fact that they need physical addresses makes them not worth using in many cases (mainly when trying to move user buffers around).

Sun supported DMA to virtual addresses in SunOS / Solaris. Made some aspects of drivers easier.

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

#270

Post by neop1x »

bogomipz wrote: post #220
Animats wrote: post #118

Mainframe designers had this problem under control by 1970. Mainframes had, and have, "channels". A channel is part of the processor architecture. It takes commands, sends them to a peripheral, and manages the data transfer in both directions. Channels have some privileged functions through which the OS tells them where the data is supposed to go in memory. The architecture of channels is well defined, and peripheral…

>"Mainframe designers had this problem under control by 1970. Mainframes had, and have, "channels". A channel is part of the processor architecture." What are some examples of these processors? I would be interested in reading more about these mainframe processors architecture. Might you or anyone else have some links?

It is always surprising for me to see how mainframes have always been one step further. I don't have any experience with them but I've learned that there have been for example live VM migrations between hosts for a long time already. And that there was a cool system called IBM AS/400 introduced in 1988 with integrated database and "everything is an object" design and peripherals with processors and which is still being used for some critical applications today. Our x86 clouds with Kubernetes may sometimes feel like a bunch of cheap toys in a way. :P
Post reply on HN