#telix — Public Fediverse posts

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

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

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

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

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

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

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

Curiously, Hugh's Linux code, I think for 2.4.6 and maybe 2.4.7, has vanished off the internet despite how things being on the internet is supposed to be eternal. I don't believe any comments within it described the provenance of the algorithms to maintain binary compatibility via subpage handling, but my memory of 23 years ago (when I looked, at which time it was already several years old) is faded enough that I can't say much for sure. Maybe it's more of the observation that the subpage handling was feasible than the algorithms, though the fault handling was more subtle than I could reproduce at the time and so would qualify. What I suspect, despite my memory not being clear enough to say with much confidence, is that the patch itself didn't say and they're original to Hugh.

#pgcl #telix

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

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

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

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

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

My favourite terminal emulator to dial BBSs was cracked Telix for DOS.

You can still use it today because we added a backend where telephone numbers can be mapped to internet addresses to @DOSBox_Staging.

https://en.wikipedia.org/wiki/Telix

#BBS #RetroComputing #DOS #Telix

BBSing with some tracker tunes tonight.

#BBS #BBSing #blinkenlights #tracker #trackermusic #mods #chiptune #Telix #DOS #PC #retrowave #mancave #vintagecomputing #retrocomputing #retrocomputers #GUS #gravisultrasound #cubicplayer #vumeter #vibe #Tandy #CRT #video #level29bbs #ByteCellar

BBSing before dinner on the Tandy 1000HX down in the Byte Cellar.

#BBSing #BBS #Tandy #Tandy1000 #Amiga #AppleII #WiFi232 #modem #telnet #CRT #demoscene #Telix #DOS #vintagecomputing #retrocomputing #setups #ByteCellar

Midnight Rendezvous with Telix: Musings of a BBS Junkie

https://brodieworld.com/2023/07/18/midnight-rendezvous-with-telix-musings-of-a-bbs-junkie/

#BBS #BBSing #DOS #PC #dialup #telix #modem #terminal #vintagecomputing #retrocomputing #vintagecomputers #MSDOS #nostalgia

Logged in for the FidoNet feed this evening.

#Tandy #DOS #Telix #BBS #BBSing #snow #NoVA #winter #vintagecomputing #retrocomputing #vintagecomputers #retrocomputers #vintagetech #computinghistory #hardware #tech #homecomputer #FidoNet

A little BBSing at lunch on the Tandy.

#Tandy #DOS #Telix #BBS #BBSing #snow #NoVA #winter #vintagecomputing #retrocomputing #vintagecomputers #retrocomputers #vintagetech #computinghistory #hardware #tech #homecomputer

@leo and @jeffjarvis got all nostalgic today on #twig (ep 738) about the "days when you bought software in a shrink-wrapped box" and made me climb up into my attic to dig out some relics from my past. We didn't actually wrap #SpySweeper, but the #Telix boxes we stuffed and blow dried ourselves.

So what are people using these days to connect to telnet #BBSes? Back in the day I used to use #Telix. And I recall using Telix in OS/2 with Ray Gwinn's SIO driver to connect to #telnet BBSes during the early 2Ks. Anything that can handle ANSI color?
#BBS