kev009 (u/kev009) - Readit News

kev009 commented on Io_uring, kTLS and Rust for zero syscall HTTPS server blog.habets.se/2025/04/io... · Posted by u/guntars

tliltocatl · 2 days ago

That's because Unix API used to assume fork() is extremely cheap. Threads were ugly performance hack second-class citizens - still are in some ways. This was indeed true on PDP-11 (just copy a <64KB disk file!), but as address spaces grew, it became prohibitively expensive to copy page tables, so programmers turned to multithreading. At then multicore CPUs became the norm, and multithreading on multicore CPUs meant any kind of copy-on-write required TLB shootdown, making fork() even more expensive. VMS (and its clone known as Windows NT) did it right from the start - processes are just resource containers, units execution are threads and all IO is async. But being technically superior doesn't outweighs the disadvantage of being proprietary.

kev009 · a day ago

It's also a pretty bold scheduler benchmark to be handling tens of thousands of processes or 1:1 thread wakeups, especially the further back in time you go considering fairness issues. And then that's running at the wrong latency granularity for fast I/O completion events across that many nodes so it's going to run like a screen door on a submarine without a lot of rethinking things.

Evented I/O works out pretty well in practice for the I and D cache, especially if you can affine and allocate things as the article states, and do similar natural alignments inside the kernel (i.e. RSS/consistent hashing).

kev009 commented on Io_uring, kTLS and Rust for zero syscall HTTPS server blog.habets.se/2025/04/io... · Posted by u/guntars

commandersaki · a day ago

I'm sceptical of the efficiency gains with sendfile; seems marginal at best, even in the late 90s when it was at the height of popularity.

kev009 · a day ago

Then you don't understand the memory and protection model of a modern system very well.

sendfile effectively turns your user space file server into a control plane, and moves the data plane to where the data is eliminating copies between address spaces. This can be made congruent with I/O completions (i.e. Ethernet+IP and block) and made asynchronous so the entire thing is pumping data between completion events. Watch the Netflix video the author links in the post.

There is an inverted approach where you move all this into a single user address space, i.e. DPDK, but it's the same overall concept just a different who.

kev009 commented on Io_uring, kTLS and Rust for zero syscall HTTPS server blog.habets.se/2025/04/io... · Posted by u/guntars

jabl · 2 days ago

To nitpick at least as of Apache HTTPD 1.3 ages ago it wasn't forking for every request, but had a pool of already forked worker processes with each handling one connection at a time but could handle an unlimited number of connections sequentially, and it could spawn or kill worker processes depending on load.

The same model is possible in Apache httpd 2.x with the "prefork" mpm.

kev009 · a day ago

I don't see anything in my comment that implied _when_ the forking happened so it's not really a nit :)

kev009 commented on Io_uring, kTLS and Rust for zero syscall HTTPS server blog.habets.se/2025/04/io... · Posted by u/guntars

kev009 · 2 days ago

FWIW Rust advice is maybe 15% of the bottom of the article, most of the decisions apply equally to C and the article is a fairly sensible survey of APIs.

kev009 commented on Io_uring, kTLS and Rust for zero syscall HTTPS server blog.habets.se/2025/04/io... · Posted by u/guntars

bmcahren · 2 days ago

This was a good read and great work. Can't wait to see the performance tests.

Your write up connected some early knowledge from when I was 11 where I was trying to set up a database/backend and was finding lots of cgi-bin online. I realize now those were spinning up new processes with each request https://en.wikipedia.org/wiki/Common_Gateway_Interface

I remember when sendfile became available for my large gaming forum with dozens of TB of demo downloads. That alone was huge for concurrency.

I thought I had swore off this type of engineering but between this, the Netflix case of extra 40ms and the GTA 5 70% load time reduction maybe there is a lot more impactful work to be done.

https://netflixtechblog.com/life-of-a-netflix-partner-engine...

https://nee.lv/2021/02/28/How-I-cut-GTA-Online-loading-times...

kev009 · 2 days ago

It wasn't just CGI, every HTTP session was commonly a forked copy of the entire server in the CERN and Apache lineage! Apache gradually had better answers, but their API with common addons made it a bit difficult to transition so webservers like nginx took off which are built closer to the architecture in the article with event driven I/O from the beginning.

kev009 commented on MS-DOS development resources github.com/SuperIlu/DOSDe... · Posted by u/mariuz

kev009 · 6 days ago

I grew up on 68k Macs so DOS was never something I thought much about aside from the occasional boot disk to run some firmware procedure later on when later Windows was well established.

Then later from a retrocomputing standpoint, I've come to see it is pretty fascinating:

1) The sheer volume of commercial software.. which is readily available on winworld, vetusware, and archive.org. A lot of it with sometimes awesome character-mode UIs (Borland's early IDEs are really spectacular, Lotus 1-2-3, and WordPerfect are still taken seriously by some users).

2) The memory model is quixotic and an interesting homage to the chaotic evolution of x86 that most later operating systems elide by requiring a 386. The 286 and 386 have drastically different protection schemes. EMS and XMS. The eventual DOS extenders and standards like VCPI, DPMI. It's honestly a mess but somehow interesting to see how people solved difficult problems.

kev009 commented on An argument for increasing TCP's initial congestion window (2024) jeclark.net/articles/tcp-... · Posted by u/cyb0rg0

kev009 · 7 days ago

This article is stuck in a very wide valley of being perhaps somewhat familiar with the domain concepts but nowhere near deep enough to draw any of the conclusions being drawn. It is close enough to being completely wrong.

The primary tradeoff of initcwnd is setting a reasonable window before you've learned anything about the path. BBR has little say on this because it takes, in relative terms, quite a while to go through its phases. An early BBR session is therefore not really superior to other congestion controls because that is not the problem it is really focused on.

Jacking up the initcwnd, you start to risk tail loss, which is the worst kind of loss for a sliding window.. especially in the primordial connection. There are ways of trying to deal with all that but they are loss predictions.

If you are a big enough operator, maybe you have some a priori knowledge to jack this up for certain situations. But people are also reckless and do not understand the tradeoffs or overall fairness that the transport community tries to achieve.

As other comments have pointed out, QUIC stacks also replicate congestion control and other algorithms based on the TCP RFCs. These are usually much simpler and lacking features compared to the mainline Linux TCP stack. It's not a free lunch and doesn't obviate the problem space any transport protocol has to make tradeoffs on.

kev009 commented on Inside OS/2 (1987) gitpi.us/article-archive/... · Posted by u/rbanffy

jeberle · 14 days ago

That is very cool. I had a similar boot disk w/ DOS 3.x and TurboPascal. It made any PC I could walk up to a complete developer box.

Just to be clear, when you say "without the need for the GUI", more accurately that's "without a GUI" (w/o Presentation Manager). So you're using OS/2 in an 80x25 console screen, what would appear to be a very good DOS box.

kev009 · 13 days ago

OS/2 had an evolving marketing claim of "better DOS than DOS" and "better Windows than Windows" and they both were believable for a time. The Windows one collapsed quickly with Win95 and sprawling APIs (DirectX, IE, etc).

It exists in that interesting but obsolete interstitial space alongside BeOS of very well done single user OS.

kev009 commented on Debian 13 “Trixie” debian.org/News/2025/2025... · Posted by u/ducktective

yonatan8070 · 14 days ago

A total of seven architectures are officially supported for "trixie":

     "trixie"
     64-bit PC (amd64),
     64-bit ARM (arm64),
     ARM EABI (armel),
     ARMv7 (EABI hard-float ABI, armhf),
     64-bit little-endian PowerPC (ppc64el),
     64-bit little-endian RISC-V (riscv64),
     IBM System z (s390x)

It's good to see RISC-V becoming a first-class citizen, despite the general lack of hardware using it at the moment.

I do wonder, where are PowerPC and IBM System z being used these days? Are there modern Linux systems being deployed with something other than amd64, arm64, and (soon?) riscv64?

kev009 · 14 days ago

Both Power and z are many billion dollar businesses each. Banking and other high finance is the stronghold for both. IBM still seems proud of z, Power seems merely tolerated these days which is a shame because it is a nice ISA and the systems are very nice too.

kev009 commented on Debian 13 “Trixie” debian.org/News/2025/2025... · Posted by u/ducktective

zvmaz · 14 days ago

> after Ubuntu went way downhill and haven't had cause to regret it.

In what way Ubuntu went downhill?

kev009 · 14 days ago

The alternative question to ask is: in what way has it gone uphill versus just using Debian?

In the early days it had a differing and usually better aligned release schedule for the critical graphics stack.

As a function of time, you are increasingly likely to get rug pulled once Shuttleworth decides to collect his next ransom.