The end of tasklets

Posted Feb 6, 2024 3:38 UTC (Tue) by shemminger (subscriber, #5739)
Parent article: The end of tasklets

The rational for tasklets (and softirq) goes all the way back to the networking overhaul that took place in 2.4 development. Back in 1999, there was a Microsoft sponsored web benchmark from Mindcraft that showed that Windows NT and IIS were faster than Linux and Apache. This was fixed by DavidM by tuning and fixing the networking stack.

It was before my involvement in Linux, so don't know the exact details but heard that was the motivation to add softirq so that network SYN packets would get processed without expensive context switch to application.

CPU vs network speeds have changed in 25 years, so tradeoffs made then maybe different.

The end of tasklets

Posted Feb 6, 2024 4:59 UTC (Tue) by iabervon (subscriber, #722) [Link]

It looks like they're not changing how it runs, just how you write the code and how it's tracked in memory. If anything, context switches have gotten more expensive relative to everything else since 1999, but that doesn't mean that the method for avoiding them can't benefit from more recent API design lessons.

Also, it's now possible to have other user space tasks that are more important and urgent than your web server performance, so it's worth being technically able to preempt it if necessary even if you normally wouldn't.

The end of tasklets

Posted Feb 6, 2024 15:40 UTC (Tue) by Wol (subscriber, #4433) [Link] (3 responses)

> Back in 1999, there was a Microsoft sponsored web benchmark from Mindcraft that showed that Windows NT and IIS were faster than Linux and Apache. This was fixed by DavidM by tuning and fixing the networking stack.

MS had noticed that the linux stack bottle-necked on a single CPU, even on a multi-CPU machine. So they improved their stack to use all four CPUs on some monster machine, and successfully flooded 4 Gigabit network cards.

They rapidly learnt not to try that sort of stunt. I can't remember how quick the community responded but, as with any perceived bugs in linux, there were fixes for the bottleneck within a day or so, and a proper solution went live within about a week. MS was left trailing in the dust ...

Cheers,
Wol

The end of tasklets

Posted Feb 6, 2024 18:07 UTC (Tue) by willy (subscriber, #9762) [Link] (2 responses)

Oh, muffin. It was 4x100Mbit. If you used a more natural 1Gbit card, Linux came out on top.

But this is, was and always has been the game. I was part of it when I worked for Intel on Linux in the mid-2000s. Team A would work on Benchmark B and produce a result that beat Linux. So we'd take a look at what bottlenecks Benchmark B had on Linux, eliminate one, rerun the benchmark. Repeat until we beat Team A. Send patches upstream. Team A would typically come back to us a month or two later with an improved result and we'd repeat until either we or Team A lost interest.

Competition is healthy, and as long as Benchmark B represents a real customer workload (and you're actually eliminating bottlenecks, not putting in special hacks for Benchmark B), this is a win for everybody. The downside of Linux basically making every other kernel irrelevant is that we've lost that impetus.

See also LLVM vs GCC, Firefox vs Chrome, etc, etc.

The end of tasklets

Posted Feb 7, 2024 10:54 UTC (Wed) by farnz (subscriber, #17727) [Link] (1 responses)

To some extent, the old thing of multiple competing forks of Linux provided the competition; if you have a choice between Torvalds, Cox, Kolivas and other kernels, where the Torvalds fork is the blessed version, and the Cox, Kolivas and other forks make different compromises to Torvalds. And then, the fact that for some workloads, Cox or Kolivas is "better" than Torvalds (but not for others) provides the impetus to work out whether there's a way to do better than all the forks include Torvalds' fork.

To a limited degree, we've seen this with EEVDF; there were the latency-nice patches floating around (and efforts made to get latency-nice to fit in with the design of the CFS scheduler), which triggered investigation into alternatives to CFS, and then inspired Zijlstra to implement EEVDF in a way that matched or beat CFS while also providing latency-nice.

The end of tasklets

Posted Feb 7, 2024 11:04 UTC (Wed) by Wol (subscriber, #4433) [Link]

> which triggered investigation into alternatives to CFS, and then inspired Zijlstra to implement EEVDF in a way that matched or beat CFS while also providing latency-nice.

And this is why Torvalds is such a good manager (and steward). He's not attached to his version, and he actively encourages these short-lived forks precisely to find the best way to do things. Which he then shamelessly appropriates :-)

Cheers,
Wol