Astral

[analog berry]

I've had that in x86 hardware also, sometimes it just races or something and does an allocation behind your back which changes the memory map

[opal lotus]

bruh

also yeah i really wish this thing had proper aml

i wonder if clanker can generate proper asl

by parsing linux driver code

[analog berry]

Doesn't it have one?

[opal lotus]

no

it's the stub shit

[analog berry]

Iirc when you showed it, it was like hundreds of objects and a thermal zone even

[opal lotus]

yes but they all just refer to a windows driver iirc

also everything needs nonstandard shit

[analog berry]

Lol

[opal lotus]

like, i get a reset when i try to access ecam

(literally works on other aarch64 hw)

[analog berry]

When you ask aarch64 people to adopt a standard

They go and manage to make it proprietary

[opal lotus]

s/aarch64/qcom/

[analog berry]

Fair

[opal lotus]

qcom is like nvidia

[analog berry]

Nvidia made an open driver at least

[opal lotus]

(no open userspace so it is still fucked)

[gritty shore]

if the company ends with com you know it's dogshit

[opal lotus]

still waiting for NVK to become good

[analog berry]

Fair

But hopefully thats coming

I dont see why they keep it closed source

[opal lotus]

yeah

IP probably

which is quite plausible

[marsh sparrow]

well, it does run Managarm (sort of)

[opal lotus]

[grand shadow]

insert graph here

[grand shadow]

"what error is returned if you O_DIRECT read into a framebuffer on linux" google searches by the utterly deranged

[bronze nexus]

why don't you just write some C to test it

Gets me close enough for 90% of things

[grand shadow]

I don't actually have a /dev/fb0 on this thing

[grand shadow]

okay, I have finished page locking/wiring/whatever you wanna call it

I just need to make one of the page in paths better (when it takes a read hint it will do a partial page in only instead)

only 72 more hours until page cache rewrite my compatriots

for that I still need to finish the proper virtio block scatter gather path, and make the filesystems properly do adjacent block reads

[prime mulch]

were u still gonna do the Advanced Buffer Cache thing

also known as the Pretentiously Named Buffer Cache

[grand shadow]

very likely yes

[acoustic peak]

What is this I would love to know

[grand shadow]

xdm working properly now

I can actually log out of root without shit crashin g

and log in as astral

[grand shadow]

acessed my uni stuff from astral

😭

[prime mulch]

Got aired by both me and mathewnd

Basically it's a silly variant of buffer cache where the data and read path are backed by the normal page cache (applied to the disk device file) but it has a bespoke write path that makes use of buffer control structures that are per-block rather than per-page

[acoustic peak]

thats kinda cool i might consider doing similar if i ever care enough to do that

i mean when i eventually choose to rewrite my page cache impl

[prime mulch]

It solves:

1. aliasing issues where if you use the page cache for metadata block writeback, you risk writing neighboring file blocks back erroneously that are aliased by other pages of the file that they really belong to, causing corruption
2. ordering issues for filesystems that need specific writeback ordering at the block level for consistency

[grand shadow]

okay wow TIL it can do that

[acoustic peak]

big brother is watching you

[grand shadow]

I've worked on making virtio block do scatter gather dma

I just need to rewrite the DPC and then ✨try it out ✨

[mild sentinel]

[grand shadow]

and once thats done all of my block drivers will now properly support scatter gather dma

then its making the filesystems do adjacent block reads, abc and make the file systems use it, and finally page cache

72 more hours

[prime mulch]

excited to see how your implementation of abc turns out

[grand shadow]

I'll have to re read our old convo to get the idea fully refreshed in my head but it'll be fun to implement

[acoustic peak]

you have NVMe right?

and AHCI?

i love SGLs with those

[formal patio]

SGLs with NVMe? do you have hardware for that?

NVMe-oF doesn't count

[acoustic peak]

what do PRPs not count as SGLs?

i scatter pages then gather them back in my driver

[formal patio]

you can take that view, sure

but NVMe has something different that it calls SGL

[acoustic peak]

ohhh i didnt realize

[acoustic peak]

that actually sounds pretty nice but my block devices are only accessed by page cache kek

[formal patio]

I don't think I have ever touched a device that supports SGLs, I don't think there is too much point in caring

[acoustic peak]

i mean its interesting

[formal patio]

even qemu only supports a single descriptor type or something like that

[acoustic peak]

speaking of qemu when are we getting that rtl8169 driver you totally promised me

[formal patio]

whenever I have time + motivation to do that

I forgot about that in the meantime, I've been doing other shit

nvidia-open debugging (hell), os-test score improvements, SIMD strcmp for mlibc, ...

[acoustic peak]

doesnt SIMD have like a single instruction that just does strcmp

[formal patio]

yesn't

depends on the exact set, and even then you need to be wary of e.g. page boundaries

[acoustic peak]

mmmm i see

[formal patio]

SSE4.2 for example:

[acoustic peak]

kill it

[formal patio]

the 16-byte wide compare is basically a single pcmpistri instruction, it just takes 3 lines of C to get the index, carry and zero from that lol

the assembly is shorter than the C++ impl 💀

I am honestly not yet sure how to impl some other stuff though

e.g. how do you implement strcasecmp_l efficiently?

just precompute masks at locale load time?

I have no idea

[acoustic peak]

in constructor perhaps

just precompute them

[grand shadow]

ok virtio block dma is done

probably going to do better rw for ext2 and then fat

[viscid flame]

who is fat

[grand shadow]

joe mama

[mild sentinel]

Weird al

[grand shadow]

weird ai

[viscid flame]

https://klipy.com/gifs/komik-15

[grand shadow]

okay ext2 and fat are done

time to do abc ig

[split lance]

wut's abc?

other than the first three letters of the alphabet

[acoustic peak]

Advanced buffer cache

[split lance]

oh duh :p

[prime mulch]

how is that duh

it's a term we made up like yesterday

[split lance]

I saw you talking about it :p so in hindsight yeah that makes sense

[prime mulch]

YOU COULDNT HAVE KNOWN MAN! ABSOLVE YOURSELF OF YOUR GUILT!

[split lance]

lol

[grand shadow]

@prime mulch okay so, I think I got it refreshed in my memory
just to confirm:

uses memory backed by the page cache
writeback directly dmas out of the page cache memory, skipping the page cache's own writeback mechanism

operation is roughly:
check if the sector is already in memory (I likely will use a trie for this) -> if not, ask the page cache for the page containing it -> keep a reference to the page -> return the memory from the page cache -> mark the abc object as dirty if needed (and increase a ref on the abc object and add to a dirty list etc) -> on writeback, dma out of page cache pages and coalescing the block i/o if possible -> when abc object ref reaches zero, free it (for simplicity) and release the page cache page

I don't think the complexity of keeping an abc object in memory when refcount reaches zero is worth it considering how quick it is to initialize when a page cache hit happens

especially since allocating with a slab cache is just extremely quick

[neon crane]

Wouldn't it be easier for the filesystem to provide a list of regions that the partition's / disk's page cache can modify? E.g. on FAT, you can only modify the first sector and the FATs, and files and directories are modified using their own page cache

Or better yet, a function that the FSD can provide that compares the desired linear offset within the partition's page cache with regions allowed to write to

And make the page cache use it and split up writes by block

[prime mulch]

no because now the filesystem driver has to be aware of that issue

rather than just being able to say "use this API set to do cached metadata access"

this is an alternative that i have considered and i thought it was ugly, it also does not solve the ordering issue

[neon crane]

I mean, as part of the "file system driver -> page cache" interface

[prime mulch]

yes that is extra code and an extra thing for each filesystem driver to worry about

[neon crane]

like the FSD would have a function called something like BlocksToWriteForPage

[neon crane]

you already have to write extra code?

[prime mulch]

also youre ignoring the ordering issue

[prime mulch]

for?

[neon crane]

the issue with doing naive page caching is that if you write to filesystem metadata, you're using the partition's page cache, and when you write to files, you're using their own page cache. and those could be at the same page offset (divide either offset by the page size)

e.g. metadata ends at some offset x * 4K + 1K, and file contents start at x * 4K + 2K and continue

page x is dual purpose

[prime mulch]

yes

[neon crane]

so what i was pointing out is you could just prevent writing to anything that isn't filesystem metadata, by adding a callback into the filesystem driver that the page cache flush-to-backing-store code would use

so for page x, only writes to offsets 0-1kb would flush

is the ordering issue you mentioned, the issue where the files' page cache is flushed to disk first and then the filesystem metadata, causing stale data to be written to each file?

[prime mulch]

no

[neon crane]

no? what is it, then

[prime mulch]

the ordering issue is that some filesystems rely on blocks to be written out in specific orders for consistency guarantees in the event of stuff like unexpected power loss

this is not easily captured with just a page cache

to fully express the orderings youd need per-block structures anyway

[neon crane]

I see, so I was trying to fix an issue not pointed out here

which filesystems require this?

i assume ext4?

for journalling purposes

[prime mulch]

basically any filesystem that has an fsck, the fsck process relies on things having been written out in specific orders to constrain the range of errors that can occur

and yeah most journaling fses need something like this

[prime mulch]

the issue you pointed out we tend to call the aliasing issue

and its another motivating factor for this

because its probably cleaner to have the filesystem just call bread/bwrite/bdirty/whatever type functions when it wants to touch its metadata than to force it to have an awareness of the aliasing issue and have extra code to identify which ranges are metadata blocks to the kernel proper (which again doesnt fix the ordering issue anyway)

[neon crane]

so you're saying it'd be safer not to use a page cache at all, and just to use a buffer cache, for FS metadata?

[prime mulch]

also yez, you should be able to reorder dirtied blocks by coalescing them into long extents to write out all at once except for ones that are dirtied with a flag that says "you cant reorder around me" (but you can still coalesce those into an extent as long as the order the blocks in the extent were dirtied matches the order on disk)

[prime mulch]

its a buffer cache backed by the page cache

[neon crane]

interesting...?

but dont you have to still solve the aliasing issue in that case?

[prime mulch]

no offense but did you not even read the conversation before you started asking questions this was all discussed

[gritty shore]

is it called ABC because it's a funny name

[prime mulch]

its becaud im fat

[grand shadow]

a big cache......

[marsh sparrow]

do you have a link to the conversation where you talk about that?

One thing to note is that for journaling file systems, the ordering guarantees become stricter

and cross multiple parts of the fs stack

for example, for the default journaling mode on ext4, the ordering is: flush data writes first, then write metadata changes to the journal, then write metadata changes to the fs (potentially from a separate checkpointing mechanism / thread / etc)

for Managarm, the current plan to solve this is:

• data pages go from page cache to disk directly (in reaction to memory pressure)
• metadata pages use a page cache but order writeback explicitly instead of reacting directly to memory pressure

and data page writeback has to issue metadata page writeback as needed (for example when allocating backing pages for a hole in a file)

[prime mulch]

how do you deal with the aliasing issue in metadata

pages

[marsh sparrow]

as in: prevent metadata pages from showing up in data page caches and vice versa?

[prime mulch]

some filesystems intermix metadata blocks and file data blocks within the same page aligned area of the disk

this can cause problems if a metadata page containing file data blocks is dirtied and gets written back

and is aliased by a page in a file page cache

[marsh sparrow]

Ah. We don't have that issue right now because we don't support such an FS yet

but that's a valid point

What do you propose as a solution?

[prime mulch]

thats one of the things that motivated this fancy buffer cache idea

basically the idea is that theres a buffer cache for metadata which is backed by a normal page cache of the disk device for reads, but has per-block buffer control structures and has a bespoke writeback mechanism

which works in terms of the block buffers and does direct IO to disk from the contents of the page cache pages

the disk device's page cache is owned by the buffer cache and the normal writeback never gets ahold of its pages bc they are never marked dirty in the normal way

[analog berry]

Have you looked into how other kernels solve that?

[prime mulch]

Yes

[analog berry]

what did you find

[bronze nexus]

Oh. That's actually a big problem with the idea of page caches per file.

My current VFS "solves" this by making the contract that the fs should ignore excess writeback data from page cache, however this is inefficient afaik.

[prime mulch]

It's a problem with using a normal page cache for disk metadata

it's not an issue for file page caches because they're virtual

[bronze nexus]

I'm not sure I understand the difference between mine and your systems

[bronze nexus]

Or do you mean by this, that file page caches read/write disk directly and a single, separate metadata page cache also does?
I.e. a system wherein they do not share the cache and yet the cache can overlap

[prime mulch]

A file page is made up of blocks from only the file

stitched together

so there's no way for it to alias anything else on disk

a metadata page on the other hand is the raw disk blocks and can contain file blocks from various different files

[bronze nexus]

Oh I see what you mean now

So the solution then is to use a cache that is more fine-grained than a page cache would be, right?

[prime mulch]

Yeah except you can still reuse the read-in machinery of the page cache since the real problems occur during writeback

hence the idea to use a buffer cache that is atop pages of the page cache but has per-block buffer control structures and a bespoke writeback mechanism that operates on those rather than on the pages themselves

[grand shadow]

Today I will implement a trie

[opal lotus]

https://docs.rs/trie-rs/latest/trie_rs/

[grand shadow]

"I am skill issued and can never write any code myself" damn

[opal lotus]

https://media.discordapp.net/attachments/766703671504797696/1198114808902451220/ezgif.com-video-to-gif_2.gif

[prime mulch]

For wap

[grand shadow]

abc

[marsh sparrow]

did you talk anywhere about how that bespoke writeback mechanism should actually work in practice?

[prime mulch]

probably it would have some kind of per volume dirty list of buffers (may or may not be a literal linked list) and it would walk this and write them out, coalescing where possible

The write would be a direct IO to disk from the page cache page contents

the part containing that block

When you dirty a buffer it'd insertion sort it into the list (or equivalent operation for other structures like RB tree) to maximize coalescing opportunities, except for buffers dirtied with a flag demanding strict ordering

Something like that

The writeback would be done by worker thread(s) periodically and when sync is called

I think I had an idea for representing extents of dirty buffers in the dirty list with a single buffer structure

and have them contain a dirty length field so that the first buffer in a dirty extent can represent the whole extent in the list

[grand shadow]

@analog berry I tried hl goty edition and it got past cdrom drm (I had to find a key online lmfao) but crashed starting a new game

[acoustic peak]

via wine?

[grand shadow]

Yeah

[analog berry]

Damn, whats the error?

[grand shadow]

It just crashes for some reason, no idea

[analog berry]

Sadge

[grand shadow]

Trie almost done

Progress been slooow

[analog berry]

What are you going to use it for

[grand shadow]

Advanced buffer cache + new page cache

Maybe I can find other places in the kernel where I used stupid datastructures too

[grand shadow]

@prime mulch I think I will have the abc be a per fs instance object rather than something that spans the whole disk, that fits better with my design and kinda also makes sense (block devices without a fs dont really need an abc, and ordered writes for e.g. journaling don't need to cross partition boundaries)

[prime mulch]

Might still want the dirty list and writeback stuff to be per physical disk

[grand shadow]

Is there a reason for this?

[grand shadow]

a nice thing about this is that this is quite similar to how my new page cache is going to be so this already gives me some solutions to problems I would face

the core of the code is set, I just need to finish some more TODOs (like abc_sync())

[grand shadow]

a b c d e f g

[opal lotus]

h

[grand shadow]

I am a chud from brazil and this is my OS

abc work continues

[grand shadow]

ok abc seems to be done

other than a TODO or two

time to switch over filesystem metadata read/write to it

another thing I need to do is finish my pushlock rewrite to fix one of the TODOs (moving it to a proper rwlock, which I did kind of write it with that in mind)

[prime mulch]

Committed?

[grand shadow]

not yet, do u want me to

its not really plugged into anything so theres no harm in commiting it

[prime mulch]

sure im interested

[grand shadow]

https://github.com/Mathewnd/Astral/blob/rewrite/kernel-src/fs/abc.c

its pretty small

[grand shadow]

damn once I finish the filesystem plumbing I think thats everything needed for the page cache rewrite to start

[prime mulch]

i have 2 comments

1 is that it might be bettter to have a global dirty thread rather than per-volume

another is that rather than running it on a periodic tick, you should start a timer for like 5 seconds into the future or something when a block is dirtied (and the timer is not currently set)

so that it never runs if nothing is dirtied

and that it fits all the potential dirtying that might be about to happen into an interval that starts on the first dirtied block

so it possibly doesnt have to wake up again

[grand shadow]

thats true

[grand shadow]

why is that?

[prime mulch]

could take up an unnecessary amount of cpu time

well nvm if youre doing it synchronously then

prob better to have per-volume threads to parallelize it per volume

but then it should be per physical disk

[prime mulch]

which is the reason for that

[grand shadow]

I don't see a big benefit in having a single dirty list per physical disk and it would add a lot more complexity around it in the kernel

[prime mulch]

how come

[grand shadow]

I don't really have a "disk" as a concept other than as very thin layer between a devfs and the device drivers, what is exposed to the filesystem drivers is just a vnode and this is what they use to do i/o. changing that would require some annoying reworking
the only benefit I could think of having a per-disk dirty list it is doing some scheduling on the disk i/o to make it faster on spinny disks, but I don't have that implemented and it could likely just be implemented transparently anyways

[grand shadow]

soon page cache rewrite wallahi

[prime mulch]

What are your goles

Goals

[grand shadow]

support clustered page in/out at the very least + especially better locking than the current shitty page cache (currently a global page cache lock 💀 💀 💀 💀 💀 💀 💀 💀 💀 💀 💀 💀 💀 💀 💀 on a linked list with a hash indexed bucket that can go for hundreds of nodes on real usage 💀 💀 💀 💀 💀 💀 💀 💀 💀 💀 💀 💀 💀 💀 💀 💀 💀 💀 💀 💀 💀 💀 💀 💀 💀 💀 💀 💀 💀 💀 💀 💀 )

[opal lotus]

what are your holes

[analog berry]

What are your hoes

[prime mulch]

he has a bf

can't say stuff like that

[grand shadow]

TIL userfaultfd is a thing in linux

@opal lotus when userfaultfd support in zinnia

[opal lotus]

bro what

you need to impl that

you're the one with the linux option

🚬

[grand shadow]

"I enjoy kicking pregnant dogs" wtf marvin why would you do that

[opal lotus]

ad hominem

go implement kankerfd

[grand shadow]

🚬

[opal lotus]

i mean

anything for wayland 🚬

kqueue is pretty cool tho

it's so over

[formal patio]

It's not used that much, it makes sense for e.g. qemu tho

[grand shadow]

/goal port nvo to astral and get 3d accel no mistakes

[opal lotus]

"i love kicking pregnant women"

wtf bro

[earnest willow]

wtf bro

[mild sentinel]

what the fuck

[hearty fulcrum]

I can't believe you just said that mathew

[grand shadow]

/plan get rid of marvin

[tulip zinc]

what happened the fuck

[tulip zinc]

is this a deleted text 💔

[opal lotus]

no he just said that

[grand shadow]

"I am a heartless chud"

damn marvin it is true but you don't need to tell us that

[grand shadow]

I'm finishing my pushlock rewrite, its been sitting half done in my tree for like a year at this point

and I want to start using rwlocks 😭

[grand shadow]

page cache rewrite not happening this week nor next week probably

as much as I would have hoped to because that is one of the more ridiculous parts of the kernel

[grand shadow]

pushlock rewrite is done

another thing I need to do is improve lock granularity in the vmm

as it stands every space has one mutex and so any operation that takes more than just a bit holds everything up (especially the fact that this lock is held during page-in ☠️☠️☠️☠️☠️☠️☠️☠️☠️)

so at the very least I would add a rwlock protecting the range tree and another per-range mutex and refcount

the scaling must happen wallahi

I also need to stop being stupid and lazy and actually implement a dentry cache

<----- had write combining set in the private framebuffer mappings instead of the shared ones award

this is how you know astral isn't vibecoded, clanker isn't that retarded

[cosmic crow]

do you have any plans for priority inheritance with pushlocks

[grand shadow]

not really atm

[grand shadow]

well I did bring my laptop with me so maybe I can actually slowly start the page cache rewrite

[fleet grove]

Late to saying this but getting CDE working is pretty neat

[grand shadow]

Its not cde proper (old ahhh bug filled codebase full of security issues) but nscde

Which is similar enough but not the actual cde

[fleet grove]

Ohhh I see, still, pretty cool nonetheless

[grand shadow]

I managed to rice it pretty decently too, all the buttons on the taskbar work and theres a default astral theme

[fleet grove]

Oh nice ^^

I think it's neat this project has evolved so much, I still remember seeing it a few years ago when it only really had the console working

Guess I need to lock in or something x3

[grand shadow]

Soon I will be fully self hosting inshallah

Just need to finish the page cache rewrite and make this 23083393893 times more scalable

[fleet grove]

Got it got it :3

[grand shadow]

A lot of the base code is done albeit untested

I gotta do writeback now

And dirtying

[opal lotus]

https://cdn.discordapp.com/attachments/1287456798407790684/1290809675943776298/assert.gif

[brazen minnow]

Managarm in a nutshell