Ich muss mir unbedingt merken, dass die langsame Reaktion auf IPIs, die in QEMU KVM nicht über Hypercalls ausgelöst werden, die Performance katastrophal beeinträchtigen kann, wenn ich das nächste Mal einen Kernel mit QEMU als Zielsystem schreibe. Mir graut es davor, herauszufinden, ob QEMU MTTCG ähnlich betroffen ist, da es im Mainline-QEMU keine solche Hypercalls gibt.

I need to make a mental note of the fact that slow responsiveness to IPIs not issued via hypercall in qemu KVM can pathologically degrade performance for the next time I'm writing a kernel using qemu as a target system. I'm terrified of finding out whether qemu MTTCG is similarly affected, because it has no such hypercalls in mainline qemu.

#Telix #QEMU #KVM #MTTCG #paravirtualisation #paravirtualization #hypercall #hypervisor #scheduling

鸿蒙 (Hóngméng) apparently is described as a distributed microkernel. I had no idea when I tacked clustering bits in the spirit of Mach's early '90s efforts onto Telix' eventual design goals that there were live efforts toward such ends. That may be the direction to go once Telix gets up to speed on a single node, provided I'm in a position to keep working on it.

#telix #HongMeng #clustering #IoT

map_anon_folio_pte_pf() et al that I see from post-7.0 code I have to merge my rolling pgcl port with appear to be helpers for dealing with multiple superpage sizes as part of the mTHP that this is the first I've heard anything of. That's moderately hopeful. With mTHP in hand, just pgcl would bring Linux' superpaging to parity with Telix', with various amounts of uncertainty as to how well either one is achieving promotions esp. in sub- allocation unit contexts.

#telix #linux #pgcl #mTHP #superpages

I have code for 1 KiB PageGrain on MIPS qemu, which should enable a demonstration of handling a case very near VAX 512 B pages while seamlessly guaranteeing within-allocation-unit promotions to 4 KiB and 16 KiB for 64 KiB allocation units and also seamlessly handling superpage promotions to sizes that are power-of-four multiples of 64 KiB. I think there may have been some testing of a similar scenario using 256 KiB allocation units on LoongArch, but while it was verified that it didn't crash, not much was done to make sure that effective use was being made of sub- allocation unit -sized superpages esp. when there were multiple superpage sizes available between the minimum MMU mapping granularity and the kernel allocation unit.

#telix #qemu #MIPS #VAX #LoongArch

Rolling pgcl forward to 7.0 and the intermediate pre-7.1 somehow resuscitated binutils issues with running LTP and DAMON on hppa and some others, but it got to having no LTP regressions vs. master on 16 arches. I still need to induce enough fragmentation within a qemu session to be able to observe non-negligible defragmentation costs that might be reduced.

#pgcl #LTP #DAMON #HPPA

For evaluation strategies, I see:
- 1. TLB-MPKI Talluri-Hill (ASPLOS '94), Navarro-Iyer-Druschel-Cox (OSDI '02), Barr-Cox-Rixner (ISCA '10)
- 2. cache pollution, maybe LLC-MPKI, originators unclear
- 3. LLC/TLB-MPKI vs. RAM scaling curves to determine „memory walls” per Wulf-McKee '95
- 4. Attribution / stack-distance modelling per Mattson '70

My own list of things I'd like to measure is:
- 1. Queueing: inter-arrival times and service times have more predictive power
- 2. Distribution fairness: the grand total never matters as much as the distribution, where fairness is a central concern, as well as priority inversion
- 3. Distribution utilisation: is effective use being made of sizes across the size spectrum?
- 4. Verification of small superpage size allocation guarantees
- 5. Fragmentation metrics
- 6. Verification of increased allocation success likelihoods for larger page sizes in the face of external fragmentation
- 7. Defragmentation overhead
- 8. Distribution to shared mappings: the highest impact can be had via sharing, so it's also a question of whether the contiguity has been distributed to the shared memory objects of greatest impact.

The MPKI notion is on the one hand a reciprocal of inter-arrival times and on the other isn't naturally comparable or extensible to service times. Wulf-McKee recast in queueing theoretical terms still doesn't cover the full range of issues I'm working on, though. Metrics for 4. distribution fairness, 7. defragmentation overhead and 8. distribution to shared mappings and maybe more need to be devised.

#telix #pgcl #superpages

qemu MTTCG (and possibly single-threaded TCG) has timer bugs keeping SMP testing of telix from being possible outside of the host system's native architecture, where kvm can be used instead. In principle, a non-tickless mode flag could work around it in the interim until fixes for the architectures involved can be cooked up, but it's likely a better idea to just skip doing any more than build testing on the affected architectures until I can get fixes for qemu.

I didn't realise that ticklessness would trip over anything like this. It's likely good that I didn't try to port to every architecture under the Sun yet.

#qemu #telix

I found CLSIZE and related code attributed to Babaoğlu & Joy in Spinellis' Unix history repo. The binary compatibility logic for the handling of MMU mapping unit -sized fragments of kernel allocation units appears nowhere within the Unix history repo. I'll have to ask Hugh Dickins whether he invented it or where he got it from.

#telix #BSD #Linux

Never mind just Linux; this would seem to raise serious issues for any group producing their own kernel without an army of lawyers on staff e.g. *BSD, RedoxOS, Graphene, ReactOS, Haiku, illumos and perhaps even plan9 and operating system textbooks and learning frameworks like FluxOSKit. There is furthermore some significant scariness about packets crossing borders rendering ppl liable for violations of all this when passing through spaces wherein USA agents may apprehend them.

https://youtu.be/SVGw0uY1dsQ

#telix #Linux #BSD #NetBSD #FreeBSD #OpenBSD #RedoxOS #GrapheneOS #ReactOS #HaikuOS #illumos #plan9 #Hurd #FluxOSKit

Ich habe gerade eine Woche damit verbracht, einen Bug in meinem Kernel zu jagen, nur um festzustellen, dass es ein Fehler in QEMU TCG ist, der dafür sorgt, dass manche CPUs keine Timer-Interrupts mehr bekommen.
(I just spent a week hunting down a bug in my kernel, only to discover that it's a flaw in QEMU TCG that causes some CPUs to stop receiving timer interrupts.)
#telix #qemu #tickless #FullPreemption #GangScheduling #AsynchronousIO #MessagePassingVFS #SchedulerActivations

Vielleicht sollte ich meinen Page-Clustering-Branch auf Linux 7.0 aktualisieren, aber ich bin unsicher, ob ich dafür ein eigenes Tag setzen soll oder was ich da am besten mache.
(Perhaps I should update my page clustering branch to Linux 7.0, but I'm unsure whether I should set a separate tag for it or what the best course of action is.)
#linux #pgcl