Virtio devices normally work asynchronously: the guest submits a request, the host processes it, and an interrupt tells the guest that the result is ready. This gives the guest an opportunity to do something else while the device is busy. But what if the application is just waiting for that one request to finish?

That’s a common situation with filesystem operations, and the reason I’ve implemented experimental synchronous queues for virtio-fs in libkrun. The idea is to let the host thread running the vCPU process the request itself before returning to the guest.

In my tests, this brought a libkrunfw build down from 7m43s to 5m34s, improved synchronous random I/O throughput, and reduced average file deletion latency by 36.1%. Let’s look at the path we’re shortening.

After rescuing and restoring a lovely Amiga 500, I decided to look for another old computer to restore. Commodore 64 machines are still relative cheap in the second hand market, specially when announced in unknown condition.

So it’s time to test and fix this lovely breadbin Commodore 64, which is almost as old as I am!

First symptoms

The machine has an intermittent boot issue. Sometimes it boots normally, sometimes it shows a black screen, and sometimes it produces random characters on the display.

Having a working Amiga 500 that’s able to run most classic games is nice, but having one that’s also able to run some of the newer software is much, much better.

The Amiga 500 comes with 512 KB of RAM soldered on the board, acting as what it’s called Chip RAM. Let’s see how much we can add on top of that.

RAM: The fast, the slow and… the chip?

Being a newcomer to the world of Amiga computers, everything related to RAM was very confusing to me. Long story short, on the Amiga 500 you can roughly have three types of RAM:

At the end of part 1 we had a clean Amiga 500, both in the inside and the outside, which we couldn’t test because the power supply that came with it was broken.

With a brand new power supply here, it’s time to find out what it works and what it doesn’t.

The first boot

While I’ve never been much of a collector myself, over the last couple years I’ve acquired a taste for retrocomputing content, avidly consuming the videos produced by people like The 8-Bit Guy, Adrian’s Digital Basement and Jan Beta, among others.

I’m amazed by the love they put on testing and restoring all kinds of old computers, and it’s definitely contagious. So, some months ago I decided to go shopping myself.

Being able to run AI models locally is one of the coolest tech things 2023 brought to the table. But given the extremely heterogeneous software stack for AI accelerators, doing that in an efficient way on your own laptop is not always as easy as it should be.

For instance, if you’re running macOS on an Apple Silicon machine, you can easily build llama.cpp with its Metal backend and offload the inference work to the M-based GPU. But can you do that from a container?