#Astral
1 messages · Page 22 of 1
Nice
try on Flanterm
@grand shadow i also didnt realize it but apparently you ported Wine too??
this is seriously awesome
congrats man
(but can you please fix the Memory: MiB / MiB string)
It """""""works""""""" (only runs some simple shit like notepad and cmd)
I need to implement /proc or a similar system call
At one point I was looking into 32 bit wine as well for playing cogmind but never went too far
So much to do and so little time to do it
if I really want to get astral popular I should just convert to some religion and call astral the new temple of it or some buillshit
god told me to build the 4th temple that will this time run minecraft under fvwm
the os will be a holy ground to run minecraft and build the temple inside it
is there something preventing modern minecraft from running?
more syscalls prob
and the modern libs
Reddit is brain food for dumbasses who think they’re smart 😭
Real
Anyways, I still gotta fix that writer deadlock from before I got in that small minecraft side quest
And possibly I should already start desigining the rewrite of the page cache
Yeah I gotta rewrite mine too 
I could probably speed it up a bunch by doing clustered page in/page out and read ahead
As it stands syncing takes a long time, but I do have a lot of the needed kernel infrastructure to do scatter gather i/o nicely
@grand shadow you should definitely try posting on hackernews again, check this out:
same post but a day later and now it's on the front page
Hmm sure
that bug was me forgetting to unlock a vnode in the rename function for ext2 and fatfs
oops
for 1.7.10 minecraft it seems like you need more than just lwjgl
Caused by: java.lang.NoClassDefFoundError: com/google/common/collect/Multimap
jesus christ you need so many libraries
idk who it was who said it only needed lwjgl but you are wrong
which MC version did you run before?
some alpha version i think
and that only needed lwjgl?
modern MC needs way more libs, but most are probably java only
$ find ~/.minecraft/libraries/ -type f | wc -l
70
yeah but there are no new native libraries
that's what i meant
they're the important ones since most pure-java libraries need no porting and even the ones that do need porting usually only need minimal changes
if it runs 1.5.2 (or maybe 1.7.10 someday) I’m happy
I have it on the todo list
Ah
Jesus christ
astral on a cubesat when
Get me into a contract with one of these companies and can be done 
doesn't your uni have something to send a cubesat?
Bro I live in brazil
I wish but no
move to italy then idk 
Talk is cheap send money
no u
Also minecraft does go into fullscreen if you press f11
Money is cheap, send talks
i think astral is a lot cooler than those *also cool managarm people
astral also isnt as awkward to pronounce
so true so real
If only you aren't dirty minded. 😏
Weird Managarm people?
believe it or not, those "weird managarm people" are the reason astral can run so much cool software
what prompted this anyways?
Seems like low effort ragebait ngl. But in case of real: bro forgets that most of the new generation of projects (let’s say started in the last 4-5 years) use at least one of if not all of the following: limine, uACPI, mlibc. I’d say that those three projects are the cornerstones of (modern?) hobby OSDev
Astral of course does deserve all the credit for debugging MC and Java and also for contributing back the changes so that everybody can benefit
but it's just rude to call ppl weird while most of them are present in this thread lol
this is completely true
i actually happen to use two of these (for the 64-bit build) and one (for the 32-bit build)
and soon to be a third (mlibc)
hmm maybe it is pretty cool then
I apologise for calling the managarm people weird
Why did you think they were weird tho, what made you say it
the real answer is unhinged 3am posting when I shouldn’t be ..
Whag the fuck
That vm has no kvm timer, no invartiant tac and no hpet
Maybe pass -M q35
I think it should be q35?
it passes hpet=off, huh
Getting a bit further with hpet=on
Huh it got stuck in ps2 init
Hmmm
My ps2 driver is a bit bad so I will save these flags to make it a bit better
But for now, I could give you a known good cmdline
qemu-system-x86_64 -M q35 -m 2g -smp cpus=2 -serial stdio -netdev user,id=net0 -device virtio-net,netdev=net0 -cdrom bootdisk.iso -drive file=root.img,if=none,id=nvme -device virtio-blk,serial=deadc0ff,drive=nvme -boot dc -enable-kvm -cpu host,migratable=off
If you dont have root.img remove the -drive and -device virtio-blk options
unfortunately it doesnt give me full control of the cmdline 😩
Forcing the ps/2 controller, whatever that toggle switch means
I think this is the next thing to do then
adding root.img
where do you initialize the ps2 controller
also i suppose you should use either tabs or spaces and not both
Wtf
nvm i found it, i guess io/keyboard.c is the generic keyboard driver
Maybe my vim config was bad or smth
Its downlowadable in https://astral-os.org/releases I think
Yeah that website
Bruh imagine having a ps2 driver so bad it hangs on qemu 
😭
Talk is cheap send patches
Tbf, if it is an old version of qemu then there was a bug that caused bad stuff to happen in ps2
A qemu bug
I ran into it in old astral
Ps2 is not that easy to drive in general
If you want to support more than just the trivial cases
since the controller is quite braindead
What are non trivial cases in ps2
Eventually 
Heh, neat
I got it running on iOS (no root.img yet tho)
and keyboard doesn’t quite work yet
Mostly that the controller is braindead and for example you can't submit commands and receive input at the same time in all cases
etc
the controller is incredibly bad yeah
Also yippe the thread hit 100 stars
Managarm only has 11 :(
@winged basin I have a question since you are more in the know about bsd stuff, can epoll be fully emulated by kqueue?
yes with a few provisos: 1) with epoll under certain circumstances you can close an FD but still have events delivered in respect of it, with kqueue you cannot; 2) epoll instances are inherited after fork, kqueues are not, freebsd just implemented a copy-on-fork feature which they found to be an adequate substitute; 3) there are subtleties around how the ancillary FDs used with epoll, like signalfd, work and these can't quite be fully emulated without implementing all these ancillary FDs too
or in short, you can implement epoll in terms of kqueue so well that i can't think of a single piece of linux software which won't work perfectly, and this has been the experience of freebsd
BUT it's not possible to be "bug-compatible" (or rather "weirdness-compatible")
this has not yet been a problem on freebsd for such diverse software as wayland and family, chromium, firefox, etc
Hmmm thanks!
I might implement kqueue or something similar instead of epoll in the future
12 now
me omw to contribute to astral to fix a bug (i noticed that its not entirely clear if the GDT init is ok, that needs fixing)
gtd init... 🥀
maybe it is time to start working on the infrastructure for the pagecache rewrite + clustered pagein/pageout
mostly making disk and fs drivers more friendly to reading sequential blocks
I already have an idea of how I am going to do the new page cache kind of,
I will keep the LRU standby list
I will switch out the dirty page list for dirty vnode list and keep an ordered singly linked list of dirty pages in each vnode
I will switch out the page hash table (which was inspired by the way SVR4 did it) into a per vnode radix tree like linux does
actually hm
if I wanted to save memory at the cost of some speed I could not have the dirty page list and just use the radix tree for that
wait nvm
that would be stupid
I do have to change how I handle stuff in the virtio block driver
currently it is read page by page, but I want to coalesce the entire read/write (even the non adjacent blocks) into a single operation
and since there are a limited number of entries in the queues, I would have to do some sort of special allocation for it
like "wait until n number of entries are free" while trying to maintain fairness
for the nvme driver I dont think major changes are needed other than properly doing the prp stuff
wonder if there is a way to easily calculate the number of pages used for the prp for the number of dma pages
if theres no formula out there I could try to find it
meh I dont think the cost of looping a few times to figure that out is going to cost a lot compared to a disk operation
either way, all of this work that I will have to do is because I did not do it the proper way at first soo
actions have consequences
@sage locust btw, since you had asked about it, brogue does work perfectly fine on flanterm
and its pretty playable (though neither the arrow keys nor the numpad arrow keys work)
so you have to use hjkl
oh right, numpad does work I just had numlock on
Doing some nvme prp work
why are the buttons trans
I think my list of things to do will be
- finish prp stuff
- do proper virtio descriptor allocation stuff
- make fatfs and ext2 more friendly to i/o on adjacent clusters/blocks
- turn vop_*page into vop_*pages
- start actually rewriting the pagecache
I think flanterm doesnt implement all xterm-256color colours
Mint probably knows that better
it does
Oh interesting
or at least it should
it's probably because of TERM=linux or something
we should add our own TERM=flanterm to ncurses ngl
isnt it a terminfo thing?
Ah didn't know that
ran into an iovec iterator bug
something is calling writev with one of the iov having count = 0
3 iovs
count = 0
count = 512
count = 0
which I suppose is valid
but my code didnt account for that
I found an alpha 1.2.6 server and alpha 1.2.6 starts, lets see if this thing can connect to it
damn
could be cuz I'm not doing mojang auth stuff
can you log into it from your host?
can't you disable online mode?
Lazy to download 50 trillion deps
Not my server
just port prism launcher
ez
i think it's qt it shouldn't be that bad
Real
Maybe Ill look into it after the pagecache work
As it stands i/o is still way too slow for general uso
Use
Right now the biggest issue is making the page cache and disk contents stay coherent during non cached i/o
With the way it currently works doing it page by page its not too difficult, but I cant do page by page when clustering
And I cant just issue a direct disk write directly without making the caches be unsynchronized
And I dont want to leave unused pages in the page cache (duplicate data!)
I am thinking of maybe making some page cache functions take a hint argument, that will let the caller control if/how clustering is done
This could also allow for a proper implementation of madvise later
But Idk if this is the best way of approaching it
Disabling USB did it
I can now type
Real
astral usb when
Makes sense as there is no usb in astral
Chatter is inexpensive, provide alterarions
this is bs why isn't there an actual error
No way real
You could try enabling syscall logging to see what is up
Or enable e9 logger
It could be a mlibc crash
i'm not gonna go to that level immediately
the exit code is 1 so i doubt it's a signal
And mlibc logs to e9 in asteal by default
How do I start the fancy desktop thing?
startwm if it is installed
Since very often mlibc crashes are silent like that
can't even use jdb
And I wouldnt put it past a rtld error
Is your kernel/openjdk patch old?
We ran into that same issue but it was fixed
Yeah
It was because of an unimplemented pipe ioctl in astral, but it should be implemented now
Unless its doing it in like the tty or something
are u trying to run modern mc?
nice
I've got the libraries for up to 1.20.4 ported but that was doing a less-silent-but-still-useless crash
So I went to 1.13 since that's the earliest with lwjgl3
Do you think you can implement that bytes available ioctl for the tty?
I think thats what it is missing
What's the IOCTL
(how would I go about installing it?)
R you running in the root.img?
I think so
Let me check it out
(Boot + login worked on the first limine entry after some tweaking, that being making root.img virtio)
If so start networking with netd vionet0 (assuming you have virtio net attached, you should)
xbps-install -S xorg-server fvwm xterm xf86-video-fbdev xf86-input-mouse xf86-input-ketyboard
Sudo will be needed for both if not running as rooot
And there might be some more packages needed, I need to make a x11-base virtual package at some point
uhh which one is the right virtio-net to use?
virtio net pci I guess
what app is that^
UTM
does this look ok? i'm not very familiar with the codebase so there might be something obvious i'm missing
(sideloaded version with JIT)
ah, apple stuff, f
Looks ok, its been a while since I last looked at the tty code but lgtm
is there a version for linux?
ketyboard
Oops I typod
oh right
keyboard*
Looks perfect, took a peek at the tty code
Yeah it's still throwing the same error
Oh huh
Interesting
Im not sure if a seek on a tty should return espipe or some other error
Since it seeking the terminal is usually done after failing the ioctl
so close to greatness
Oh did you close the vm before without syncing
yeah i'm looking at it now and it shouldn't be possible to reach the seek if the ioctl succeeds
I have no idea what I am doing so that is very well possible
can I fix somehow
Redownload the image and next time you close the vm do a proper shutdown or run sync before closing it
root.img or the booting one?
root.img
I did not wait until it was safe to shut down my computer..
rebuilding the disk image is incredibly painful with this directory on there
takes such a long time
Ioctl can have a return value so maybe thatt should be set to zero?
I forgot if I do that automatically
Result pointer in tty call
Damn thats bad, bug in a lot of ioctls in asteal I think
nah i just checked it's initialized to 0
Oh
Nvm then
My batrery is 9% so I might end up not responding if you find a possivle bug
Ubtil like 40 mins
it's actually an mlibc bug!
as far as i can tell at least
well the root minecraft thing
Nice
Yooo holy shit
What were the mlibc bug and deadlock
And can you load a eorld
Dlopen makes mlibc panic when it's called from JIT'd code
my favorite version
Haven't figured out the deadlock yet, it sometimes happens after an LWJGL 3 crash so I went back to the latest version that uses LWJGL 2
how playable is it?
On absolute lowest settings (including 2 chunk render distance) I get 10-20 FPS when standing still after chunks generated
some optimizations to be done i guess
Is this a good enough showcase screenshot
Also what's the cmdline argument for multicore llvmpipe or whatever
LP_NUM_THREADS
Hell yeah this is so cool
Maybe get a neofetch
How do I get a second terminal
wow indeed
Does f3 mention anything about astral
unfortunately not
what does it say?
Hell yeah
guess we should be able to run gtnh now
this is the highest fps i've been able to get
prob
Real
still pretty good
i wonder what slows it down that much exactly
is it spamming some syscall or something
no gpu accel maybe?
well it is an old mesa version apparently
Now find a offline mode mc server and join 
llvmpipe is very fast
strange then
is there hope for sata support someday
why
Yeah if I get the time to write that
funnily enough 1.12.2 works fine while 1.7.10 breaks when clicking the singleplayer button in the main menu
Wtf
and when i say break i mean crash
Soon
which is annoying because on any minecraft version i've tried so far when the game window closes the kernel panics
so i can't read the crash report
Is it a localsocker thing
If so I have the fix on a local patch
this is the only part i can read
Im not home but when I am I can push the localsock fixes
Yup
Thats the bug I fixed
sick
The issue is that java or whatever does a writev with iovecs ghat are like
len = 0
len = 512
len = 0
And that breaks the iovec ringbuffer code
yeah this seems kinda restrictive
My fix was to just skip 0 bytes at the start of every for loop lnao
increasing it to 64k locally and seeing if that fixes 1.7.10
actually it seems that the 1.7.10 singleplayer crash induces a different panic
Spooky
yep that did it
that's just an informative number mlibc returns, it's not actually authoritative
the best minecraft version
that happened when mc crashed due to emfile, when i raised the fd table limit the panic also disappeared
Oh
Ill add that to my todolist of bugs to look at, since that should not crash the kernel
i don't think that's what caused it directly, mc still had time to create a crash report and all, it only crashed when the window closed
just like the other window close crashes except this time it had a different panic
Hm
me with hv singleblocks because no PTFE 
Just handcraft ptfe for a single lcr to automate ptfe vro 🥀
fair but nitirc acid is ass
Yeah lmao
yooo pog
damn, 40-60 FPS in the overworld
needs optifine
the way optifine launches mc on 1.7.10 is incompatible with java >=9
yeah gtnh has a different mod
we will see

Hype
inb4 monkuous disappears for 2 years to beat gtnh
Gtnh playthrough in astral
Good idea
Dont think so
Dont see why it would
Llvm is used only for mesa and mesa uses dynamic linking anyways
no not the kernel that's done by the window closing post-crash
ah damn
lwjgl3 segfaults in some native function
Hm
You need to rebuild mesa after building llvm
But mesa has a stable abi
ah ok good
less good: llvm patch fails
how am i supposed to update the patch again
If the localsocket crash is too big of an issue you can add an iovec_iterator_skip to the start of the for loops in iovec.c
If you skip 0 bytes itll end up skipping the 0 sized iovecs without skipping any real buffer
I forgot
You were saying?
( @carmine swallow did it yesterday)
i was saying "just port it" in response to "but you need to download all the libraries by hand"
I’m more of a technic launcher enjoyer myself
Never used it lmao
makes sense considering it's multi platform
i use it on both windows and linux
and i haven't seen usable gtk on windows yet
isn't firefox gtk?
Likely then
Gimp?
sodium maybe?
sodium is only for lwjgl 3 versions iirc
Did you find anything more about the lwjgl 3 crash?
haven't really investigated yet
Damn
ok fun fact with the llvm+mesa update AVX support is required
both minecraft and glxgears crash with SIGFPE
Interesting, I wouldve thought itd crash with sigill
Makes sense
Btw, when the mlibc pr gets merged dont update mlibc in astral, itll need a world rebuild and a new openjdk patch
Since I am behind a few abi breaks and stuff
good to know
ah llvm wants AT_PAGESZ and the assert to check for !=0 gets compiled out
And for that patch he’s stuck on me debugging Java font shit (which is also why managarm doesn’t have Minecraft yet). We continue that today
Ah yes we ran into that too
Not that difficult to add
Easy fix yes
@grand shadow just to confirm, openjdk on astral has JIT enabled right?
Indeed
Its enabled by default and you can disable passing -Xint to the jvm
astral replacing linux when
in 2204
btw, did this end up having any improvement or did you hit a bug?
or llvm took too long to compile :P
First time minecraft was beaten on a hobby OS?
Update was successful but improvement was minimal
holy shit
how playable was it overall
Honestly surprisingly playable if you're willing to put up with low render distance
daaaamn
But a lot of frame rate hitches and low render distance isn't really viable in the end fight
So the end fight was done at 10-15 fps
Not to mention when the dragon decides to throw 6 particle bombs and the framerate drops to single digits
it was stable too? no crashes or anything?
No crashes, but there was some weirdness at times that caused me to reload the world (things like lighting not updating when placing torches)
Probably just some worker thread being overloaded
Ok for some reason the end credits are incredibly laggy
astral is stable enough for a full playthrough of mc lets goooo
maybe framebuffer idk
I doubt its graphics related tbh
Maybe some syscall in astral being ridiculously slow
Plus lack of vdso
There probably isn't an easy way to profile the whole system unfortunately
I can confirm though that most of the MC frame time is taken up by rendering terrain
🔥🔥🔥
According to the MC builtin profiler
Which is expected but nice to know it's not some non-graphics-related performance issue on astral
yeah maybe its just the overhead of running in a vm + no avx or whatever
are you running the latest llvmpipe with all supported instruction sets ?
I'm gonna try to add xsave support (aka avx) and see if that helps
that would be great
and recompile llvmpipe?
I imagine llvmpipe would discover it on the fly
llvmpipe is a JIT for graphics
year of the astral desktop 2026
implementing xsave in astral is more work than i thought because the entire codebase assumes that the context size is known at compile time
Yeah that code is ooldoold
Think I wrote it in 2023 but took the idea from old 2022 astral
and does xsave not provide a fixed size context or what?
nope
with xsave you select a bitmask of features and then query cpuid to get the size
so here's how I'd solve that problem: DO NOT add xsave registers in the context frame. instead, allocate a separate region in the thread struct called xsave_state and save and restore into that. the kernel doesn't use MMX/SSE/SSE2/AVX so you're safe to do it right inside the function that switches the current thread (and also reloads cr3, gsbasekernel, etc)
astral has this concept but that, too, has to be fixed size
signal processing assumes the entire context (including fp) is a fixed size struct
like
struct thread {
//...
void* xsave_state;
};```
dw i've already made the changes necessary to implement xsave
that's... bad
i'd solve it by pushing the xsave state first and then the rest of the context
then when returning from the signal handler pop the xsave state after everything else
kinda like how strings are stored later in the stack in the information block and then earlier in the stack there are pointers to areas inside the information block
(talking about argv and where each character string inside argv is stored)
however i realize you're way more experienced than i am
so maybe you already thought of this
how did it affect perf?
thats a lot
fps numbers?
trying to get to a place where i can do an actual comparison
I can try on my cpu with avx 512 tomorrow if you give me the IMG
and now the 2nd ever minecraft hobby os completion
verdict on AVX: it definitely helps. this was much more playable, especially during the end fight (the most directly comparable part of the run)
that's sooo cool! 
Hell yeahh do you have any specific numbers?
Good work btw
pre-AVX dragon fight felt like 10-15 FPS when not much was going on and 2-5 FPS when one of those particle bombs was on the screen
post-AVX dragon fight felt like 25-30 FPS when not much was going on and 10-15 FPS when one of those particle bombs was on the screen
but i didn't actually do a proper measurement with either setup
Oh yeah that is defo much better
image (xz compressed): https://we.tl/t-l7N3XeL99D
qemu command: i personally use qemu-system-x86_64 -display sdl -accel kvm -M q35 -cpu host,migratable=off -smp 8 -m 32G -bios /usr/share/edk2/x64/OVMF.4m.fd -drive file=bootable.img,format=raw,if=none,id=nvme -device nvme,serial=deadc0ff,drive=nvme
steps to run mc: in xterm do ```sh
cd /minecraft
LP_NUM_THREADS=<cpus> ./run.sh 1.12.2
1 file sent via WeTransfer, the simplest way to send your files around the world
Also, in the same dir as run.sh, that image contains a Python script that can download the libraries and assets for any arbitrary Minecraft version (theoretically, because I've only tried it for 1.7.10 and up)
Might be useful if you want to test an older version
sodium when
apparently needs lwjgl 3 which currently crashes
I should add an installation manual to astral-os.org at some point
I already have the step by step written down, I just have to make it a bit more verbose
i have important information
nobody keeps that coherent
you have to explicitly invalidate the page cache if you want it to be coherent with the file data on disk after doing a noncached write in basically every OS, and you also have to explicitly flush it if you want cached writes to be visible to noncached reads
ok i lied apparently O_DIRECT does that for you on Linux but it doesnt do it in a write-updating way
see here
they invalidate the entire range of pages in the page cache
oh, and thats only advisory
it can fail on pages that are dirty in the range and they ignore failures, so dirty pages just stick around non-coherently
so indeed theres no guarantee of coherency until you do explicit invalidation, they just make a best effort
does this make your life easier at all @grand shadow
hmm
most of my worries for this are because of the way I cache filesystem metadata, I directly use the disk's vnode to do that
this leads to the issue where obviously filesystem metadata can share the same page as file data and, as file i/o is obviously not cached as to not have duplicate data in memory, this could lead to one overwritting the other during writeback at some later point
I could try find another way to cache metadata and actually make non cached i/o completely ignore the page cache
do u want to know how NT manages that
sure thing
too bad its a secret
jk
they have a generic in-memory data structure they use for keeping trees of on-disk extents which is intended to be used by filesystem drivers to efficiently translate from file offset -> disk offset
this is also usable as a very efficient mask they can add and remove ranges from
basically the fs drivers create a fictitious file with special handling for reads and writes
which redirect them to the underlying disk
but first, in the write path, it masks it off with the aforementioned data structure
potentially splitting up the write and removing some sectors from it
whenever they need a sector of metadata, they add it to this mask
so that writeback will work
so basically, a special type of "metadata vnode" that when written back to disk it does some special handling to not overwrite things it shouldn't?
I did think of doing something like that at some point, so knowing a real os does that it seems like that is the way to go
to be specific about what this is btw
is its a data structure that supports these operations with the intent of being used to cache file offset -> sector lookups:
- add discrete mapping from given virtual offset to given physical sector
- remove discrete mapping from given virtual offset
- look up physical sector given a virtual offset (or inform caller somehow if not found)
and it does this with an AVL tree of extent structures that represent a contiguous virtual->physical range
which it tries to keep as merged as possible
to minimize memory usage and depth of the tree
they reuse this as a mask for metadata writebacks by:
- to add sector to mask: add a 1:1 virtual->physical translation
- to remove sector from mask: remove virtual translation
- to check whether sector is in mask: look up virtual translation and see if present
it happens to work as an efficient structure for basically keeping a bit mask of metadata sectors across the entirety of a large volume, where each contiguous run of set bits is represented as a single in-memory extent structure with a base and length
theres an alternative which is to use a page cache backed buffer cache specifically for metadata and thats what i was thinking of for mintia2
see here and onward for my description of the idea #lounge-0 message
basically you back the buffer cache data with mappings from the page cache and you reuse the read-in and demand paging logic thereof
but these pages are never written out with the normal machinery
instead the buffer cache has its own write-out logic that operates on disk block granularity (and tries to cluster appropriately and whatever)
and uses noncached IO from the page cache pages to the underlying thing
okay I think I understand it
say inode 1234 is at sector 123456
you could have the metadata file be structured as something like
superblock | group descriptor | bitmaps | inodes
and so to write to that vnode, you first tell it that at offset of inode 1234 in it, rounded down to sector size, is sector 123456
then you write to it as you would any page cache backed vnode
when its time to write it back to disk, it uses the sector mappings to write out the dirty pages, if present in the mappings, to the correct sectors without overwriting things like they would on page sized writes
yeah
for NTFS they actually designed the on-disk filesystem around this to completely avoid needing to do that
by having all of the fs metadata be like pseudo-files on disk
including the disk bitmap and the inode table (MFT) itself
so it Just Works like it works for any other files
hmmm this seems smarter than the naive way I was originally going to approach all of this, which was to just tell the page cache how many pages max to cluster in and go syncing and evicting them as I go instead of directly doing block I/O (kind of what I already do for non cached i/o but with the cluster limits)
yeah no the naive way would not work efficiently at all
this also has a cool benefit that you can like
when you mark a buffer dirty you can say "i want this to be written out in the order it was marked dirty" which forbids it from coalescing it into a bigger write potentially out-of-order with other dirty buffers
and when you want you can enforce block-granular ordering
which is useful for journaled FS implementation
and stuff
this is impossible to do with the "metadata mask" thing because the write-out logic is still page granular
NT's solution is to make pages that contain metadata that is sensitive to ordering (like the NTFS log related stuff) exempt from normal write-out and at specific safe moments it performs basically a big "barrier" which writes it all out to disk synchronously before proceeding to the next thing
i dislike this
I still got some ground to cover before I get to this so I will think about which way I am gonna approach this
thank you for your wisdom mr hyena man
i did the metadata pseudo file thing in old mintia and it made me feel like the Advanced Buffer Cache idea is the btter one
thats just my input
i dont know of any implementation of the ABC (thats my name for it that ive coined just now) currently out there
maybe the UBC in netbsd is something like it idk
I do find letting the filesystems just ask for specific sectors rather than add handling for an entire metadata file cleaner
well there was one really cool thing with the metadata file
you know how youre supposed to mirror the fat in fat12/16/32
whenever you write to it youre meant to write to the other mirrored fats simultaneously
the NT (and mintia) FAT driver has a cool solution to this which is whenever a write comes in to the metadata file and is targeted at the FAT, it is split into a handful of equivalent IRPs which are redirected to the mirrored FATs and dispatched to the disk driver asynchronously in parallel
so you only have to modify the FAT once and only have to store 1 page of it
and the writeback of FAT pages is automatically split to each mirrored FAT
i cant imagine doing that particular thing in any other way now i know that epic sauce way exists, plus fat metadata is restricted to a region at the start of the volume and its extremely easy to clip metadata writes so they dont exceed that region and that solves the problem
so ill probably still do specifically FAT metadata that way because its the best way
but for other fs drivers ill use the ABC thing
damn I get like 3FPS, but that might have to do with WSL tbh
i might try with vmware as well a bit later
thats smart
did you come up yourself with the abc thing btw
do you allocate a small descriptor for each sector?
probably, from a cache with magazines and slabs and so on
i havent actually implemented it yet
mintia2 io stack is gonna be terrifyingly complicated and im still stalling it
by doing other stuf and trying to read up on other modern io stacks in the meanwhile
ah so likely what I would end up doing as well then
so basically:
fs asks for sector 1234
abc checks page cache for page containing sector 1234, loads in page and allocates descriptors for the sectors if not there
fs then writes to sector 1234
abc sets the sector as dirty in the descriptor and adds it to a dirty list, as well as dirtying the page
page cache starts writeback of dirty pages, calls into abc put_pages() or whatever
abc manually writes the dirty sectors to disk and sets them as not dirty
no its more like
- fs asks for sector 1234
- abc looks for sector 1234's descriptor. if it doesn't find it, it allocates a new one and associates it with the correct location in a demand paged mmap'd window into the disk (these windows are themselves cached, maybe in the generic file viewcache). it then refs the underlying page (preventing page-out) and returns it.
- fs then writes to the sector and calls abc to mark it dirty
- abc sets the sector as dirty in the descriptor and sorts it into its own private dirty list ordered by LBA to reduce seek times. doesnt bother setting the page dirty because the page cache is uninvolved in writeout. it also increments the refcount on the underlying page again to reflect that theres a dirty sector inside it (or increments the refcount on the sector to reflect that it is dirty)
- fs releases buffer for sector 1234 which removes the first refcount on the page
- later, abc's own lazy writer thread walks the list of dirty sectors, marks them clean, and initiates clustered noncached write-outs to the disk
- when these write-outs complete, the underlying pages for each sector are unreferenced, allowing them to be demand paged in and out
the cool thing about this that distinguishes it from a traditional buffer cache is that the sector data is 100% pageable in and out of the system, the same way as any other file- or device-backed page, during any time where there are no actively referenced sectors within the page
a reference to a sector is held while the fs driver for example is actively making use of it and also while the sector is marked dirty
probably there'd be a refcount inside the sector descriptor where, when its incremented to 1, the refcount on the underlying page is also incremented to pin it into memory
further references dont need to up the refcount on the underlying page
when the sector's refcount drops to zero, the page's refcount is decremented and the descriptor is inserted into a list of reclaimable descriptors (or just freed outright depending on if theres any value in caching the descriptors themselves, considering the underlying data is still cached by the page cache and so the descriptors are theoretically disposable as soon as their refcount hits 0, at the expense of extra setup time later)
during low memory situations youd also probably want to kick the abc's lazy writer into action alongside dumping other dirty pages to disk in order to free them up
okay so, just to confirm, the descriptors are in a separate tree structure for the lookup with the sector as the key and for the window I think I could just get it from the page cache and point it to the hhdm of the page
about the sector refcount dropping to zero, I think the simplest implementation would be to free it, that way standby pages dont need to hold info about attached descriptors in their struct pages
they wouldnt need to hold that info anyway
thats the reason its a demand paged view
so if the page is yeeted
and you look up the sector descriptor and go to touch it
you just fault it back in
hmmm
okay I think I understand this
and its way cleaner than the file thing I think
by the way the reason that the page is held pinned in memory while the buffer is being used by the fs driver is IO errors
when you look up a sector, the abc needs to fault in the page if its not there and then pin it
and if the page fault results in an IO error, it needs to convert that to an error status return
rather than crash the system
this is a real concern for like network filesystem stuff
the abc could be acting directly on a mapped view of a network filesystem if its, say, a mounted disk image that resides on an nfs server
if it didnt pin it in a safe way first then any access to the metadata by the fs driver could result in a failed page fault due to IO error which usually leads to a crash if unhandled
I dont support demand paging in the kernel (cringe ik) for simplicity but I dont think thats a hard requirement for abc
yeah
you still need to pin the page for a different reason
which is to avoid the hhdm location becoming reused
by the page frame changing hands
yeah
I think I will implement abc, I like it
thank you
you've always been a good inspiration to get better on kernel design
@prime mulchso in your design, this advanced buffer cache thing would apply to just the metadata, or the entire disk?
for example on ext2 would it apply to the inode table, inode bitmap, and block bitmap separately, or as one whole structure?
(FAT really only has one piece of metadata which is the, well, FAT)
Managarm uses a page cache for all of these ext2 bitmaps / tables
but of course it's not accessible to userspace applications
separately or together?
also my OS currently has a page cache that applies to the whole disk, which is bypassed specifically for files and directories. but i don't yet have write support so this probably won't stick
i see i see
this is easy on ext2 since the numbers/locations/sizes of these structures are fixed (after fs creation)
got lwjgl3 working
turns out it was an issue with libffi (it assumed malloc returned rwx memory)
does fabric or forge works ?
wtf
probably
What was the fix?
fwiw i'm pretty sure managarm has this issue too
adding a defined(__astral__) to an existing block of ifdefs
which one?
diff -urN --no-dereference libffi-clean/src/closures.c libffi-workdir/src/closures.c
--- libffi-clean/src/closures.c
+++ libffi-workdir/src/closures.c
@@ -139,6 +139,9 @@
executable memory. */
# define FFI_MMAP_EXEC_WRIT 1
# endif
+# if defined(__astral__)
+# define FFI_MMAP_EXEC_WRIT 1
+# endif
#endif
#if FFI_MMAP_EXEC_WRIT && !defined FFI_MMAP_EXEC_SELINUX
CC @prime juniper
fwiw this is what the entire ifdef block looks like ```c
#if !FFI_MMAP_EXEC_WRIT && !FFI_EXEC_TRAMPOLINE_TABLE
if linux && !defined(ANDROID)
/* This macro indicates it may be forbidden to map anonymous memory
with both write and execute permission. Code compiled when this
option is defined will attempt to map such pages once, but if it
fails, it falls back to creating a temporary file in a writable and
executable filesystem and mapping pages from it into separate
locations in the virtual memory space, one location writable and
another executable. */
define FFI_MMAP_EXEC_WRIT 1
define HAVE_MNTENT 1
endif
if defined(_WIN32) || defined(OS2)
/* Windows systems may have Data Execution Protection (DEP) enabled,
which requires the use of VirtualMalloc/VirtualFree to alloc/free
executable memory. */
define FFI_MMAP_EXEC_WRIT 1
endif
if defined(astral)
define FFI_MMAP_EXEC_WRIT 1
endif
#endif```
@sharp carbon can you try pls 
it's on my to do list
nice
also on my to do list are "get 1.20.4 working" (latest version to use java 17) and "see how much sodium helps with fps"
whats needed for 1.20?
Considering that mint reported >100 fps with llvmpipe on linux at 1080p there must still be some bottleneck on astral
fwiw gtnh also has a modern fps increase thing
well backport of a modern thing
so it doesn't work very well
it has a weird crash i'm investigating
damn y'all are running minecraft now?
I'm never catching up to any of you at this rate 
all u need is some sysdeps
i'm about to start elf loading now
a lot of sysdeps I guess?
then i can try userspace
a decent amount yes
theoretically all you need is code to map the interpreter and a main executable
And for your vmm&pmm not to cause a kernel panic when you do literally anythin
and a way to communicate to the userspace process those details
well thats hopefully covered by tests
i need to do CoW too
somehow
and i'm rewriting my allocator to support non relocatable elfs
I'm sorry what
what does your allocator have to do with non-relocatable elfs
Have you been loading relocatable elfs as programs???
And what does that have to do with an allocator?
you need to allocate space for the elf, no?
Normally a kernel will support loading static (and static-pie) ELFs directly, and defer to a userspace interpreter for ET_DYN
lol, neat
i wonder if there are any extra patches that Astral has that should be backported to Gloire
or managarm
Yeah but you also need to allocate to e.g. implement filesystems properly. You wouldn't call that "adding support for vfs to the allocator", would you?
i meant that the allocator would reserve the specific address and not use it
you should mmap the elf in memory
i did not have support for that
You need to look into virtual memory
you can do it using private anonymous mmaps and just read the file in
but thats slow and crappy
?
Don't ask any more questions about ELF loading until you know what virtual memory is. If you've got questions about virtual memory, go to the channel with the same name.
i do know...
You seem not to
wdym...
please don't backseat mod
What has this got to do with backseat modding
I meant it more in a way of I don't want to pollute the convo here
in general we let thread owners make that judgement, there is no rule against off topic talk in a project's thread if the owner is fine with it
plus the way you said it seemed (to me) a bit rude
Sorry. I have a very short fuse for people being confidently incorrect.
Holy
How
Even on my gtx 1650 super I get less on mc I think
this is what i get with llvmpipe on absolute lowest settings on vanilla 1.20.4 linux
Crazy
on the same settings with my actual gpu i get 1100-1200 fps
pid 134 tid 136: In function getprotobyname, file ../../../base_dir/sources/mlibc/options/posix/generic/netdb.cpp:360
__ensure(!"Not implemented") failed
pid 134 tid 136: mlibc: panic``` lovely, this is preventing the jvm's debugging features from being used
Wonder what the biggest peef bottleneck is
Is this with sodium?
nope, completely vanilla
Stealing this and applying it this evening. Nice catch
do you have any clues about what the crash is?
working on something to diagnose that since the java debugger doesn't work
@prime mulch so am I correct in understanding that the mf, which is basically the inode table, is cached in the kernel address space in a similar manner to other cached files in NT?
And it's mapped there... permanently?
getprotobyname does block it from working but even with a stub implementation it hangs on connecting to the jvm
i think it's an issue with astral's tcp implementation
uh oh
and even if connecting to the vm did work, it wouldn't be worth much, because even enabling the debugger agent makes the jvm crash upon initialization
i decided it was too much effort to look into it properly
my work shall continue today:
todolist: finish prp stuff, do virtio block descriptor allocation and scatter gather stuff, make filesystem rw better for fat/ext2, implement abc, rewrite page cache to make use of the new infrastructure for things like clustering
is that a msg by MC?
Looks like it
Yeah that's something from Minecraft initialization
It's for updating old world to the current version
That'd require either the source code or linux bin compat
And IIRC Astral isn't Linux bin compat
So... I guess you've got TF2?
found the culprit of the mc init hang: net stack again! specifically, it's waiting without a timeout for the results of an api request
Damn, I guess somewhere I dont return an error if a route cant be found
Unless you were running with netd which then bleh
considering ssh 127.0.0.1:22 also hangs i doubt it's something routing related
i'm not going to look into it that far but i'd guess that's a good starting point for debugging
I can try taking a look
the solution i'm using is to just stop recognizing AF_INET at all
socket(AF_INET, ...) now always returns EAFNOSUPPORT and that fixes the issue for me
i suspect this same issue is part of what's preventing jdb from functioning since that also communicates over a local tcp port
anyway, behold:
yoooo real
i think it might be something with my tcp code not properly relaying back to the tcp client that the port is not open
I swear I had something like sending a RST
but that might not work or I might be misremembering
wait holy shit
fabric???
yep
the way i debugged the issue is by writing a fabric mod that println'd at various places in the mc code
okay this is much less stable than 1.12
it's hitting an mlibc panic pid 234 tid 236: In function thread_mutex_destroy, file ../../../base_dir/sources/mlibc/options/internal/generic/threads.cpp:130 __ensure(!mutex->__mlibc_state) failed pid 234 tid 236: mlibc: panic
that assert is supposed to be an error return
hm so I do send a reset, back, so I guess my connect() is at fault here for not handling receiving one
according to the pthread_mutex_destroy manpage anyway
oh neat another mlibc bug found
Attempting to destroy a locked mutex results in undefined behavior.
is that the posix 2024 docs or the linux manpage
because the linux manpage says no such thing and in fact specifies the behavior
that's from POSIX
POSIX says that the impl may return EBUSY
but yeah as a quality of implementation issue it probably makes sense to follow glibc here
you can PR that fix in if you want to
ok, I both incorrectly handle the refusal of connections and there is an issue when the nic is not initialized
fun stuff
if I try talking to it from the host using tcp without running netd it doesnt even appear in the wireshark
cant tell if thats a user networking thing or what
what is netd?
my half assed dhcp client
i just use a tap device for debugging Managarm
so that i can have the VM directly in my home network
that requires you to have a bridge on the host with your ethernet attached though
I am running in wsl so its kinda difficult lol
but anyways, I think it might not even be tcp related (?)
looking at the wireshark dump properely the host is arping but nobody is responding and even the host doesnt time out
I'm not sure what the way to handle this is
damn even with sodium i only get 10 fps
wtf
so no improvement at all?
nope
does the f3 graph show anything weird?
nah it's completely expected, ~75% of root is gameRenderer and ~90% of that is terrain
is maybe xorg not using shared memory?
idk how to check for that
that'd explain why it's slow 
☠️
for some reason astral doesnt want to boot on windows qemu
I use an old version of limine and that has been known to have trouble in windows
fuck
i suspect most of sodium's improvement relies on not being cpu rendering (these are linux measurements, same scene in each, default graphics settings aside from vsync and fps limiting):
- vanilla:
- radeon: 600-700 FPS
- llvmpipe: 10-15 FPS
- sodium:
- radeon: 1300-1400 FPS
- llvmpipe: 13-17 FPS
how would i check for that and enable it if it is indeed disabled
minecraft after 1.8 sucks anyway 
these are the extensions reported on Managarm
astral doesn't have that, can't be bothered to port it while I'm busy getting gtnh to work
does it even require porting? isnt it a compile option or something
it probably doesn't need porting but it definitely requires supporting infrastructure
do you have the specifics
if you remember from managarm
i know that ironclad uses the shmget backend of it but Managarm doesn't have that
so it must be using something else on Managarm 
probably either memfd_create or O_TMPFILE
hmm
i'll check if i can spot it in the source, one sec
fixed
do u want me to upstream it
actually, it's either of these: https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/Xext/shm.c#L1217
yes please, I don't like keeping the af_inet disable thing around
ah still needs some more debugging hold on
or nvm
I tried sshing to a random port of my vps but it seems like linux didnt even send a RST back 💀
it might be blocked by the firewall
yeah I have a firewall in the vps that must be it
🥀 I forgot I had that on
anyways @sharp carbon fixed reset code should be up
issue's still there
just bare 127.0.0.1 already worked, the issue occurs when 127.0.0.1:22 is passed
don't know why that makes a difference but it does
that doesnt work even on the host
yeah but it hangs on astral instead of erroring
the hanging is in turn what causes minecraft to hang on init
hm
a response never happens to the udp request
now the question is if mlibc supports a timeout
and if so if astral does it properly
timeout for what?
dns response
yes
I dont see it in the lookup_name_dns function
unless its something external
indeed it does not
will be implementing timeout
its not mapped permanently, they cache 256kb mapped views of files which are tiled across a large region of kernel space
@prime mulch what do you think of fishOS?
When is mft specifically unmapped?
when the volume is unmounted i guess theyd destroy all of the fcbs (basically vnodes) and at that time any outstanding views would be deleted. they also unmap unused views and reuse them if they run out of them
whats that
@prime juniper figured out the java font issue: the X11 font code special cases linux if an os-specific fontconfig.properties isn't found (https://github.com/openjdk/jdk/blob/dfacda488bfbe2e11e8d607a6d08527710286982/src/java.desktop/unix/classes/sun/awt/X11FontManager.java#L699-L705
oh wow
did you run into that while trying gtnh
but yes, that was the issue
yes
damn
i fixed it by editing the isLinux check to include || osName.startsWith("Astral")
so did we
but i suppose the more "proper" way to solve it is to include a fontconfig.properties

@analog berry
lol, let's send this screen in the gtnh discord
unfortunately not
f
damnit
real
did it say anything more about the error or are we just in the dark
trying to figure it out
it marks this as "errored"
there's this but the backtrace it mentions does not exist
ah nevermind it's just not in the scrollback buffer
send the output to your host terminal
so, under memory pressure?
I'm asking because with a caching system like in NT, I understand when and how they unmap regular files from the cache, but the mft case seems more interesting, at least for me
memory pressure wouldnt necessarily cause that, because these mapped views are demand paged so they can just do normal paging without destroying the view
if that makes sense
its like how when a mmap'd file's pages are paged out, the file isnt munmap'd, you just fault on it next time you touch it

yeah, I was worried about wasting space on that
Lol yeah thatd be funny af
Is that some internal corruption?
Btw how many years did it take to load into the game
not that long actually
