<bslsk05>
'Yakuza Kiwami: MesuKing | Giant Petail vs Giraffe Stag-Beetle' by Old Shinji Plays (00:04:29)
<geist>
okay, can we try to stay a bit on topic?
<heat>
what the fuck
<zid>
yakuza's always got like.. super high budget pisstake minigames in it (solaris is amazing)
<heat>
solarissss
<heat>
lets stay on topic
<mjg>
ok, real question
<heat>
what the hell is doors anyway
<mjg>
who can name a good quality vm paper
<heat>
i legitimately have no clue
<mjg>
talking about handling fork et al
<heat>
no idea
<heat>
i like the one where they say fork is bad
<heat>
not a vm paper but a process creation one
<zid>
fork is kinda bad
<zid>
(is geist gone yet?)
<zid>
(that was a joke)
<geist>
hmm?
<zid>
YES I LOVE BSD
<heat>
mjg, the problem with good quality vm papers is that they mostly don't exist
<zid>
(shit I think he heard me)
<mjg>
heat: this is my suspicion, but i did not search really hard
<heat>
because linux doesn't really have many papers on it
<heat>
:)
<geist>
huh?
<heat>
you have cranor i guess, then some memory allocation stuff which touches vm
<heat>
including vmem
<heat>
but people don't bother writing this stuff down
<mjg>
well i'm talking about the same issues tackled by the uvm paper
<mjg>
but other approaches
<zid>
okay I thought of a question
<heat>
linux is at a point where there's no good mm/vm documentation because no one wrote it
<heat>
people "just know"
<zid>
what happens if my thread is idle loop because it's blocking in a syscall, but an NMI happens, do I need to double-wrap it so that my syscall doesn't get pregnant
<mjg>
normally people get special stacks for this
<heat>
not like you're getting an NMI anyway
<mjg>
NMINCEL
<zid>
yea I mean, I probably just won't get an NMI
<zid>
but it likes to fuck with hlt still right?
<heat>
yeah
<heat>
so you wrap it in a loop
<geist>
indeed
<zid>
(so that my syscall doesn't get pregnant)
<geist>
is this an actual question?
<heat>
im also confused
<heat>
it sounds like an actual question but with a nice finishing touch of stupid
<zid>
what was wrong with my question
<geist>
can we try to be a little more... normal? seems the channel has gotten a bit silly and aggressive lately
<geist>
can we just be a little more cordial?
<zid>
it's been amazing lately, who hasn't b een cordial? O_o
<heat>
yeah
<geist>
remember we're also trying to make sure that anyone lurking, or newbies can feel safe asking questions
<zid>
oh wait I have half the channel ignored actually don't I
<geist>
if it turns into a insular, joke around thing too much it can turn folks off
<heat>
mjg, anyway, maybe try looking into linux? i know you may have issues looking cuz @freebsd.org and whatnot
<heat>
linux deals with vm object chains by just not having them at fork
<heat>
as in, they mark PTEs WP
<heat>
(write protected if that's not clear)
<mjg>
ye i really don't want to lok at that code
<heat>
the only chain they can end up having is MAP_PRIVATE mapping -> page cache
<zid>
see heat you're the only one who wants to cheat and stare at linux all day
<geist>
well, it avoids the chain until something writes to one half of it
<geist>
then they have to clone some sort of internal object, i assume
<geist>
(i honestly dont know how linux does it's VM either)
<heat>
they clone it at fork
<geist>
but you said they were avoiding the object chain. you think they clone the objects, but just point them at the same fundamental page?
<heat>
I don't know if they do a deep clone or if they do a shallow clone and don't actually store the entries in the "vm objects"
<geist>
i guess that could work if your page table is the high level mechanism to track stuff
<geist>
yah
<heat>
yeah pretty much
<geist>
it's definitely a 'weird' design by traditional design rules
<heat>
the logic for COW, non-present faulting, map shared WP is all in the page tables
<heat>
which is something I ended up emulating
<geist>
yah no matter what you do you gotta WP all the mappings for sure
<heat>
you basically get a weird pte state machine
<heat>
you can assume that if a MAP_PRIVATE page is write protected and it got write faulted, you're supposed to COW
heat has quit [Remote host closed the connection]
heat has joined #osdev
<heat>
otoh, you can assume that if a map_shared page is WP'd and got write faulted, you're supposed to set up writeback and un-protect it
<heat>
cheers router
<heat>
<heat> you basically get a weird pte state machine
<geist>
yeah
<zid>
heat what client is that
<heat>
irc client?
<zid>
it's copying all the colour codes and emoji and stuff
<zid>
when you quote
<heat>
i use hexchat
<heat>
it happens if I double click the message, if I select everything it doesn't copy colour
<heat>
it's weird
<heat>
anyway yeah, that's how linux handles fork and COW
<heat>
it's relatively weird but it makes sense
<geist>
i think part of the compleixty there is it i think has to jump through hoops with shared mem
<heat>
why?
<geist>
basically the fast path assumes that a given page is mapped once. and thus a single page table has all the data needed to track the page
<mjg>
so i'm probaby going to take a serious look at freebsd vm in few weeks. i can do cheap cop out to make scale better while keeping the vm obj chaining
<mjg>
or i can try to revamp the thing
<geist>
and once it goes shared i think it needs more data structures
<heat>
for COW?
<geist>
yah
<geist>
but in the posix api that doesn't happen super often, so it's the uncommon case
<heat>
yeah i don't quite understand how linux does MAP_PRIVATE file fork
<heat>
oh no it happens a lot
<heat>
for every executable and shared lib
<heat>
s/understand/remember/
<geist>
well, MAP_PRIVATE Is fairly easy: if it's private, either the pages are already marked write, in which case its already a private copy
<geist>
and if it's RO, then it's part of the underlying thing and doesn't really need any more work on it
<geist>
so you'r really kinda doing a COW clone of an anonymous object that overlays something underneath (the file)
<heat>
yeah
<heat>
what other case do you have?
gog has quit [Ping timeout: 265 seconds]
<geist>
a full RW mapping that's already shared, like a non private mapping of a file
<geist>
or a shmem
<heat>
that's still pretty clear
<geist>
i dont actually prcisely know the semantics of that on a cow
<geist>
er fork
<heat>
oh, it just stays mapped
<geist>
and no cow?
<heat>
no cow
<heat>
it's shared
<geist>
so that also avoids the problem
<geist>
because of semantics of fork
<heat>
file shared has the following state machine "not present -> mapped wp -> faulted (un-wp) -> *writeback* -> mapped wp"
<geist>
what i would worry about is scenarios where as a side effect of fork, the VM has to go chase down N RW mappings of the same page, scattered across a bunch of address spaces
<heat>
I believe MAP_SHARED is just a stupid mapping of a bag of bytes
<geist>
but if fork says things that are private are COW, and things that are shared remain shared, then posix avoids most of the headaches of that
<heat>
why would you need to do that? for fork
<geist>
what happens if you map the same object multiple times in the same aspae? i guess you can't really do that with posix without either a non private file mapping of the same thing
<geist>
or... shmem with yourself
<geist>
in which case, same semantics: doesn't get cow cloned on fork
<geist>
since that's now a shared mapping and not eligable for cow
<heat>
yeah
<heat>
even if they were cowed, you could just flip the WP switch
<geist>
i think in contrast this is where non posixy VMs have trouble, since they probably allow more mappings to exist in more states
<geist>
and dont have fork to think about
<heat>
wait ah, I think I see what you mean
<heat>
like a private mapping of a page, that is then remapped somewhere else. how do you make that COW only once
<heat>
right?
<geist>
yah i guess in the posix api that just cant happen
<heat>
yeah
<geist>
since the only real way to multiply map something you have to opt in via an api that explicitly makes it a shared mapping
<heat>
linux vm itself is super "optimized" for posix
<heat>
as in, there's no vm_object
<geist>
this is where we painted ourselves a bit into a corner (or not, depending on your point of view) in zircon: vmos are intrinsically not shared in shared
<heat>
you have anon vmas, and file address_space's
<geist>
they are simply an object. you can map them 0, 1 or infinity times. there's no fundamental different
<heat>
there is no generic thing
<geist>
but that means that effectively they're like a shared mapping in linuxes world
<geist>
if you cow clone it, it has to go find all the mappings and WP them
<geist>
doesn't have any shortcuts
<heat>
yeah
<geist>
i think NT's VM is fundamentally similar in that the design is not posixy and probably intriniscally allows more things
<heat>
that sucks
<geist>
in the shared area at least
<heat>
do you still have that linked list or are you doing something fancier?
<heat>
i remember last time we checked linux was doing some sort of bullshit rb tree
<geist>
linked list, but there are solutions for it to at least reduce it to O(N) per times actually mapped
<heat>
where it's not really an rb tree
<geist>
just haven't done them
<geist>
including a tree, but i dont think the tree helps in this case that much, for he common case: a VMO is either mapped 0 times, once, or a lot
<geist>
and in the lot case, it's usually the whole vmo
<geist>
so those are the problematic cases
<Matt|home>
so if my math is wrong (it probably is).. if we have a 24 GB system, and i dictate that we _only_ permit wordsize alignment addresses without doing complicated math to stitch them together period, we still have 375MB of ram left to work with :D plenty of space for links and a filesystem
<geist>
hmm?
<Matt|home>
plus imagine how much faster memory access would be
<geist>
in what context?
<heat>
geist, maybe just establish COWing a vmo as a poor idea?
<heat>
if there's no way to go around it in zircon vm, just say "this is bad, dont do this if you want perf"
<geist>
oh sure, but it's the loader thats the one doing it
<geist>
because it's mapping somethig like libc.so over and over again which it should be able to
<heat>
ohhhhh yeah
<geist>
no no this is fine. i'm not saying we're screwed or anything, it's just ramifications of choices here and there
<geist>
the larger thought experiement is 'how does linux avoid these problems' and the answer seems to be something along the lines of posix not allowing a bunch of situations to occur
<geist>
and thus you can optimize around it
<heat>
well it's a particularly poor corner where you're gonna have to WP everything?
<heat>
or at least look at everything
<geist>
well, that can be fixed
<heat>
which can maybe be solved but... yeah
<geist>
there are solutions, they're just a paint
<geist>
pain even
<geist>
note i'm not actually talking about the cow clone issue. infinite cow chains is another problem altogegtierh
<geist>
i'm talking about the 'how do you deal with a vmo that's mapped a bunch of times and you need to manipulate one page on it'
<geist>
actually linux will have to deal with this too, i dont think anything can aovid it
<geist>
but i'm sure they have some fast data structure to deal with it
<heat>
wait
<heat>
why are you COWing everything again?
<heat>
for the libc.so for instance
<heat>
like, you're mapping libc.so cow. you create a VMO that's COW (through magic interfaces I don't know by heart)
<geist>
ie, i have a page in a vmo that's mapped 100 times, and in 56 of those mappings the page is currently in a PTE
<geist>
but you want to reclaim the page. how do you efficiently find the 56 PTE entries and shoot them down
<heat>
woah that was a burst of msgs
<geist>
sounds like your router is choking right now
<heat>
yeah
<heat>
oh right yeah
<heat>
linux does a bullshit rb tree
<geist>
i think linux avoids the N PTE entry problem in the general case by having most vm objects mapped exactly once
<geist>
so it's O(1)
<heat>
details of which I won't pretend to understand
<geist>
yah, probably some table that reverses pages to mappings
<geist>
that's the general solution. either a table, or some data structure hanging off the page, or all of the above
<geist>
that's what we'll have to do in zircon at some point to reduce O(Mappings) to O(number of times page is actually mapped)
<heat>
>having most vm objects mapped exactly once
<heat>
that doesn't work for MAP_SHARED
<heat>
which is the really big pain point
<geist>
yes that's what i'm talking about
<heat>
where you need to go through /every mapping/ and WP/de-WP them
<geist>
ie, every OS has to deal with it at some point, unless you just dont have shared pages at all
<geist>
yep. or unmap them because the page is being reclaimed/swappedout/compressed/etc
<heat>
totes
<heat>
oh yeah funny thing
<heat>
my linux system uses swap now!
<heat>
as in, actually uses it
<geist>
noice! yah i always use swap on mine, and generally set swappiness to 100
<heat>
i wonder if there were chances relatively recently
<geist>
like put those pages to use!
<heat>
i used to have to sacrifice a goat for 1GB of swap usage
<geist>
procps top also has a nice swapped column that you can add per process
<geist>
handy to see which ones are actually using it
<heat>
also zram is *bad ass*
<heat>
and actually usable in servers
<geist>
but yeah something changed about linux that makes it a bit mroe eager to swap, even without swappiness set to 100
<heat>
i wonder how MGLRU is going to affect this
<heat>
geist, here's a weird question: are huge pages not viable because they're not viable?
<heat>
as in, not viable -> no OS uses them much -> cpus dont add many TLB entries for those -> not viable
<mjg>
not viable?
<geist>
oh i think they are used somewhat
<heat>
yeah
<geist>
also keep inmind what you describe is largely an x86 thing
<heat>
i mean, not viable as in "you can't use them much"
<heat>
if you spam them it's an anti-pattern
<geist>
and an intel x86 thing iirc. i think zen has had merged TLBs since day 1
<heat>
which is why THP is disabled often
<geist>
also a thing i suspect they picked up from K12
<heat>
orly?
<geist>
i thnk so, hang on.
<kazinsal>
re: swap being constantly utilized, I think as both primary and secondary storage sizes ballooned and speeds for both increased dramatically (thanks, SSDs and insane DDR clocks) kernel designers started more and more dramatically adhering to the philosophy of "free RAM is wasted RAM" and started applying that to swap too
<geist>
yeah i'm fairly certain i'm right: zen has combined TLBs
<kazinsal>
with performance of random access to swap no longer being beholden to mechanical seek times there's no real reason not to use it more often
<geist>
whcih is also something that all ARM cores i know of do too
<geist>
kazinsal: yah thats my thought too
<\Test_User>
I avoid using it so it doesn't wear my ssd out early
<geist>
yah that's a valid concern
<kazinsal>
my machine is apparently using 23.3 GB actively, the rest for cache, and 52.4 GB of swap
genpaku has quit [Remote host closed the connection]
genpaku has joined #osdev
<heat>
woah
<heat>
huge ass swap you have there
<kazinsal>
yeah, twice the physical RAM size
__xor has joined #osdev
__xor has quit [Client Quit]
<geist>
i remember BeOS's swap was pretty silly but kinda interesting: the swap (if present) had to be >= sizeof(ram)
<geist>
and did not allow overcommitting
<heat>
aw
<geist>
so it did something kinda silly like literally assign every slot in a object a logical page number
<heat>
overcommitting is all the fun in vm!
<geist>
which was either in ram or in swap
<geist>
why swap needed to be at least as big as main memroy i forget
<heat>
hibernation?
<geist>
probalby not, this was before that sort of thing was a thing
<\Test_User>
did it work if had no swap, or there must be a swap that is >= ram size
<geist>
now that i think about it, i actually dunno what's up there. not allowing overcommitting was kinda in vogue in the late 90s
<geist>
if there was swap it had to be >=
<geist>
no swap was valid too
<\Test_User>
seems odd
<geist>
something like maybe it mapped all pages + the 'extra' pages to a slot in the swap file directly
<heat>
I like windows's autoresizing page file
<heat>
it just makes sense
<geist>
and thus it always knew where to write a page to
<heat>
no user should ever need to deal with that
<\Test_User>
ah
<heat>
I wonder if the kernel does it, or if it's a service
<geist>
agreed. once i saw how linux does the swap with a file in the fs, i'm not really afraid of using that nowadays. generally dont use swap partitions anymore
<heat>
yeah but I'm fairly sure you can't resize it
<epony>
you can't do anything after cryptolocker asks for bitcoins ;-)
<geist>
oh sure. no. you can keep adding and removing them
<geist>
kinda gets you a similar thing
<heat>
yeah
<heat>
which kinda sucks but oh well
<epony>
let's fill the root partition with growing files.. neat idea
<heat>
i don't think adding resizing would be very hard though
<heat>
either do resize_swap(new_len); truncate(file) when truncating down, or truncate(file, new_len); resize_swap(new_len); when truncating up
<heat>
i dont see why it would not be able to handle it
<heat>
maybe linux's swap format is too bad
<epony>
"I am so smart I write operating systems as my day job and never care about learning what the systems I criticise actually do, but I also lack some teeth cause I fall on my face regularly" --Qanon MSFT deviant
<geist>
well, you have to do mroe than resize it. have to also allocate the blocks (cant be sparse) and then effectively pin them in place
<epony>
and sometimes, encrypt the contents..
<geist>
what seems to happen is the VM subsystem gets a block list from the FS and then holds onto it in some structure so it can directly blat to the underlying disk
<geist>
so that's why it generally helps to have a lesser fragmented swap file, but no matter what you do it must be fully allocated or it rejects it
<heat>
yeah
<geist>
i think the windows swap thing does basically the same thing, but i guess it's a little tighter coupled with the VM and FS
<heat>
replace truncate with truncate + proper block allocation
<heat>
idk if there's a fallocate call for that
<geist>
whatever fallocate does
<heat>
i think generally people tell you to NOT use fallocate for swap files
<heat>
precisely because it sometimes doesn't allocate blocks
<heat>
(as in, fs dependent)
<geist>
ah possibly.
<epony>
with a bit of thought, we're slowly distilling the concepts behind partition types and their slices..
<heat>
seems to in ext4 though
<geist>
whats interesting is it bypasses the disk cache. if you hexdjmp your swap file or whatnot you actually might not read what's there because the swapper skips any cache blocks that may exist for the file
* heat
laughs in boomer filesystem
<heat>
oh yeah totally
<heat>
have you done that experiment with /dev/sda and a file?
<geist>
similarly if you fallocate with ext4 for example, it may mark the run as allocated but not zeroed
<heat>
it works the exact same way
<geist>
so if you read the file back you get zeros, but the swapper writes to the underlying blocks
<heat>
the way linux vfs works, it divides the block device in $block_size chunks
<heat>
but only metadata is accessed using the caching mechanisms
<heat>
for pages, it maps the block buffers directly on top of the page
<heat>
s/pages/page cache pages/
<epony>
this year, next and previous years might differ
<heat>
so this means that if you look at /dev/sda1's filesystem metadata, you'll find consistency
<heat>
if you look at a file, you won't find it unless it's sync'd
<geist>
makes sense
<epony>
remember inodes
<heat>
and if you write it in /dev/sda1, cat file will hold the in-core contents
<heat>
it's trivially observable using filefrag and a file
<heat>
and do believe I hate this solution, but it's the only valid one
<heat>
the big issue with all this is that the block device is also mmapable
<heat>
which is why you can't truly unify them AFAIK
<heat>
you mostly just make sure you use caching when you want caching, and raw block io when you're already doing caching, or in swapping
<geist>
i always liked the bsd rdev vs dev nodes. no idea if they're still there, etc
<epony>
remember buffer cache
<geist>
but makes general sense
<epony>
you should really read a book ;-)
<heat>
what's that?
<geist>
huh i dont see them on this freebsd install. maybe they were removed a while back
<geist>
the gist was the r* versions of the block devies were raw. uncached, and can only be accessed in block sizes iirc
<geist>
probably not mmappable
<kazinsal>
net/open still do rdev nodes
<heat>
i remember netbsd wanted to get rid of the distinction between block devices and char devices or something
<heat>
at least I remember reading something about that in tech-kern a year or so back
<geist>
OSX seems to still have it though: /dev/disk0 vs /dev/rdisk0
<geist>
anyway i guess it all doesn't really matter, but i thought it was kinda nice to use the r versions with dd and whatnot when you know what you're doing
<heat>
was thinking the same thing about getting rid of block
<heat>
to mount(2) and mount(2) can be adjusted to use a block device
<heat>
devices. The only place they should ever be used is an argument
<heat>
underneath when it is handed a character device. FreeBSD got rid
<heat>
of block devices a long time ago. Doing that as a first step is
<heat>
likely to simplify things to make other things easier.
<bslsk05>
en.wikipedia.org: Raw device - Wikipedia
<mjg>
one thing freebsd is doing than the rest is devfs
<mjg>
you don't get /dev/whotfknowsifevenconfugired42069
<mjg>
nodes
<heat>
yeah i see some discussion about that here too
<mjg>
and it's not a hack like in linux either
<heat>
i should resub to tech-kern
<mjg>
doing better*
<heat>
lots of fun discussion there
<geist>
yah i've always thought devfses were a fundamentally good idea
<heat>
dh` doesn't like it :(
<geist>
oh i think there are downsides and compromises for sure
<mjg>
there is a devfs paper by phk, but have not read it since high school
<heat>
i feel silly, let me find this on the archives
<mjg>
it made sense to me at the time :-P
<geist>
but it makese sense to me at a high level: if the kenrel contains drivers, and the drivers are detected and initialized by the kernel, it makes sense for methods to access the drivers should be exported by the kernel via a coherent mechanism
<klange>
something I decided a long time ago was that I was just not going to do traditional 'device files' with hidden id numbers, all of my device files are virtual, effectively all mount points of their own 'filesystems'...
<geist>
and the first os i seriously programmed on (beos) had a devfs, so it kinda stuck to me
<bslsk05>
en.wikipedia.org: Device file - Wikipedia
<mjg>
ye one great thing is that you are no longer screwed by major/minor numbers
<mjg>
this bit just works(tm)
<geist>
i get the udev mechanism by linux being ultimately more flexible, since it's a user space decision, but it seems pretty icky
<mjg>
i owuld not call it more flexible
<mjg>
what happened there was that linux had "actual" devfs, but it was incredibly buggy
<heat>
i think udev these days takes a devfs and mutates it around a bit
<mjg>
so they wrote a cop out
<heat>
dev 3.9G 0 3.9G 0% /dev
<geist>
sure, but in the end the udev stuff does have some advantages. in the same way that folks would say systemd does too, etc
<heat>
on a system with udev
<epony>
obsd does not have these
<geist>
ie, it's a user space thing that can decide what to do based on <insert coplicated logic here>
<mjg>
geist: like what
<heat>
rename ethernet devices to topological names
<mjg>
maybe i should not freebds lets uerspace react to various device events
<mjg>
see devd
<geist>
decide the permissions and the user/group that a node appears as
<epony>
devfs, procfs, sysfs - gone
<geist>
or what the name is, tc
<epony>
(and not coming back)
<mjg>
geist: again see devd
<mjg>
you can do all of it
<geist>
i dont know what devd is
<heat>
mjg, i'm saying that's literally how udev works these days
<geist>
again i'm not saying thera rent *other* solutions, i'm just talking about udev
<mjg>
geist: i'm saying you can do the same stuff you are mentioning here *and* have actual devfs
<heat>
it mounts devtmpfs
<geist>
solaris i think had something kinda similar: they had a /devices mount iirc that the kjernel published and then something in userspace would symblink over to /dev based on rules
<geist>
which is... what you're describing
<mjg>
heat: right, how much of a devfs is it though?
<heat>
it's totally usable in its own right
<heat>
embedded frequently uses it
<geist>
anyway. what is devd?
<heat>
freebsd's udevd it seems
<mjg>
geist: devd – device state change daemon
<mjg>
notify 10 { match "system" "ACPI"; match "subsystem" "Resume"; action "/etc/rc.resume acpi $notify";
<geist>
ah. so does it get first shot at a device changing?
<mjg>
};
<heat>
yeah that's udev with a mustache
<mjg>
no, it does not have a say for the kernel creating a node
<mjg>
but if you insist you can chmod it after
<heat>
neither does udev with devtmpfs
<geist>
what beos did was something like that too: some daemon (device_manager i think) would basically inotify on the /dev tree and wait for stuff to appear
<mjg>
ye some conceptually it's all in the same ballpark
<kazinsal>
iirc permissions were just owner/world access until v4 when they went "well we're rewriting the rest of the system in C we might as well add some security bits to the filesystem"
<bslsk05>
github.com: make/getloadavg.c at c93ec39d1079224f28ebb5797243d38266a1d066 · wkusnierczyk/make · GitHub
* mjg
imagines unrelaed gmake runs which all decide to gtfo
<heat>
well gmake looks at the load avg if that's what you're asking
<heat>
probably to decide to dispatch jobs
<heat>
ah yes, the classic avenrun
<heat>
truly vintage
<mjg>
i presume it tried to throttle iself
<mjg>
but if all the gnu makes do it...
<heat>
reading that code is truly wonderful
<heat>
all the ifdefs
<mjg>
classic unix experienceman
<heat>
Copyright (C) 1985-2016 Free Software Foundation, Inc.
<bslsk05>
wiki.postgresql.org: Fsync Errors - PostgreSQL wiki
<epony>
the misc, the tech and the ugly
<kazinsal>
every once in a while on my end basilisk will appear to vomit out a page description completely unprompted
<epony>
cause you've stuck your head in the sand like heat
<heat>
lmao
<klange>
-l [load], --load-average[=load]
<klange>
Specifies that no new jobs (commands) should be started if there are others jobs running and the load average is at least load (a
<klange>
floating-point number). With no argument, removes a previous load limit.
<mxshift>
on-die temp sensors are going the way of loadavg. It meant something at one point but now it's a complex situation distilled into one unitless number that everyone insists on putting a unit on anyway
<raggi>
Load average is still useful
<kazinsal>
for the most part the only thing I really care about on-die temp for is thermal throttling
<mxshift>
so are the unitless "temp" sensors
<raggi>
It's not a good way to schedule work though
<epony>
check out how well htop is working / usable on BSD
<kazinsal>
but given that any machine will just go "yep, it's hot" and dial itself back nowadays it's not super useful to me from a numerical perspective as much as it is that it exists
<kazinsal>
I can use "I am 80% of the way to being Too Goddamned Hot" probably a little bit better than I can use "I am at 72.8C"
<epony>
that starts to make sense when you know what it means on your system
<mxshift>
kazinsal: that's exactly what they are designed to report now. It roughly correlates to celcius but it actually just tells you how close to throttling you are
<klange>
but I want to use my temp sensors as a thermometer :(
<mxshift>
well, knowing margin is important
<mxshift>
at least when building fan control that isn't boneheaded
<klange>
heat: it seems that direct i2c drivers have overtaken ACPI access, for reasons unknown
<epony>
"we fix everything, you just donwload our software" --zfs4bsd
<heat>
:|
<heat>
well I'm willing to bet they're probably still mostly smbus based
<heat>
which means your smbus driver for ACPI will be reusable for $fan_mechanism!
<heat>
yay!
<epony>
obsd does not have zds, and the dtrace there is own implementation btrace
<epony>
zfs
<epony>
so about nothing can be reused in a BSD UFS/FFS
MiningMarsh has joined #osdev
MiningMarsh has quit [Remote host closed the connection]
<epony>
also there is no in CPU softECC ;-)
<heat>
mxshift, how are you avoiding the FSP?
<mxshift>
well, it's AMD
<heat>
ah
<heat>
well, that's great :)
<heat>
also AGESA uses an FSP interface so i'm still technically right lol
<mxshift>
but we avoid AGESA by incessantly asking them for docs and running lots of experiments so we can do the init ourselves in illumos kernel
MiningMarsh has joined #osdev
<heat>
yup, that makes sense
<heat>
you're doing platform init in illumos?
<mxshift>
yup. x86 reset vector lands in PHBL. PHBL setups up very minimal environment (page tables, etc), loads a cpio archive from SPI NOR into RAM, extracts unix fromcpio archive, loads it according to the ELF headers, and jumps into it
<mxshift>
everything else is in illumos
<heat>
that's *very* cool
<heat>
intel seems to be stuck on the "server = UEFI" wave
<heat>
and i understand why "hurr durr protect precious Intel IPs" but...
<mjg>
ASSERT(ap->an_refcnt != 0);
<mjg>
if (ap->an_refcnt == 0)
<mjg>
panic("anon_decref: slot count 0");
<mjg>
not gonna say what system is this
gxt has quit [Remote host closed the connection]
<mxshift>
not far from a code path I found in a GPT parser. It panic'd during boot after I had been doing random write testing on raw block devices.
<heat>
we totally need bryan cantrill here
<heat>
just sayin
<mxshift>
except in that case, it checked a few things very carefully and then blindly trusted an LBA specified in the GPT header
<mxshift>
be careful what you ask for heat
* heat
gets popcorn
carbonfiber has quit [Quit: Connection closed for inactivity]
<epony>
asking for CHS would be a bit too late at this stage
<epony>
even if you're not careful to ask about it
<bslsk05>
[From: Chris Lattner  To: linux-kernel vger kernel org, orbit-list gnome org  Subject: ANNOUNCE: Linux Kernel ORB: kORBit  Date: Fri, 8 Dec 2000 17:10:47 -0600 (CST)   This email is here to announce the availability of a port of ORBit (the  GNOME ORB) to the Linux kernel. This ORB, named kORBit, is available from  our sourceforge web site (http://korbit.sourceforge.net/). A kernel ORB  allows you to write kernel extensions in CO
netbsduser has joined #osdev
<froggey>
didn't realise that was from Chris Lattner, somehow that makes it so much better
doorzan has joined #osdev
epony has quit [Remote host closed the connection]
GeDaMo has joined #osdev
potash has quit [Ping timeout: 246 seconds]
potash has joined #osdev
<mjg>
// NOTE: Atomic flag doesn't support simple atomic read (by design),
<mjg>
// so instead we test_and_set and then clear if necessary.
<mjg>
// This function is only used inside assert, so we don't need
<mjg>
while (atomic_flag_test_and_set_explicit(&lock->flag,
<mjg>
memory_order_acquire))
<mjg>
;
<mjg>
}
<mjg>
:[[[[[[[[[[
<kazinsal>
I feel like if it has some kind of "it is only used inside X so we don't need to Y" attached to it it should be named something like spinlock_lock_DANGER_WILL_ROBINSON
<mjg>
the first one is only in asserts, but there is 0 reason for it to be this fucking stupid
<mjg>
but the real crown jewel is spinlock_lock
<mjg>
which is the quintesential "don't do it like that" spinlock
<dh`>
applying a membar on each iteration is great too
<moon-child>
mjg: what
<moon-child>
why
<moon-child>
why is that a thing
<moon-child>
;-;
<mjg>
so much to unsee
sortie has quit [Quit: Leaving]
sortie has joined #osdev
<mjg>
makes me wonder, did templeos guy ever vist here?
<kazinsal>
long ago
<kazinsal>
several times he had been banned from the forums as well
<kazinsal>
followed by getting banned from pretty much every other forum in existence
<mjg>
:)
<mjg>
figures
doorzan has quit [Ping timeout: 268 seconds]
\Test_User has quit [Quit: .]
\Test_User has joined #osdev
\Test_User has quit [Client Quit]
\Test_User has joined #osdev
nyah has joined #osdev
zaquest has quit [Remote host closed the connection]
smach has joined #osdev
smach has quit [Remote host closed the connection]
zaquest has joined #osdev
smach has joined #osdev
rurtty has joined #osdev
isaacwoods has joined #osdev
SpikeHeron has quit [Quit: WeeChat 3.6]
smach has quit []
_xor has joined #osdev
lkurusa has joined #osdev
SpikeHeron has joined #osdev
epony has joined #osdev
k8yun has joined #osdev
DanDan has quit [Read error: Connection reset by peer]
SGautam has joined #osdev
Starfoxxes has quit [Ping timeout: 265 seconds]
Starfoxxes has joined #osdev
clever has joined #osdev
bgs has quit [Remote host closed the connection]
scaleww has joined #osdev
DanDan_ has joined #osdev
heat has joined #osdev
<heat>
mjg, what's that spinlock_lock?
<heat>
where's it from?
dude12312414 has joined #osdev
isaacwoods has quit [Quit: WeeChat 3.6]
k8yun has quit [Quit: Leaving]
<mjg>
heat: helenons
<sham1>
spinlock_lock. Ah yes, the famous NOUN_VERB
<zid>
that's why japanese is the superior language for programming
<CompanionCube>
mjg: it would be funny if someone posted kdbus and cited korbit as 'prior art'
<pbx_>
what way do network stacks usually handle ARP requesting? Queue or drop IP packets with unknown targets?
nvmd has quit [Quit: WeeChat 3.6]
nvmd has joined #osdev
heat_ has joined #osdev
heat has quit [Read error: Connection reset by peer]
netbsduser has quit [Remote host closed the connection]
heat_ has quit [Remote host closed the connection]
heat_ has joined #osdev
<mjg>
CompanionCube: lol @ kdbus
<mjg>
CompanionCube: i remember how it was posted to lkml claiming perf improvement, with blindly claiming userspace dbus just can't keep up due to context switches
<mjg>
CompanionCube: then someone decided to get a profile from it and what do you know, tons of retardation
<mjg>
erm, i mean someone wrote it efw years back, must be good then
<bslsk05>
en.wikipedia.org: List of vaporware - Wikipedia
<mjg>
epony: lol
<epony>
that list includes MacOS too ;-)
<epony>
and Vista
<epony>
maybe it should have a link to Plan9 too..
<epony>
and SunOS/Solaris ;-)
<mjg>
OH
<mjg>
add sparc
<epony>
CDE ;-)
<geist>
pbx_: oh sweet! grats
<mjg>
there should be a badge or smething for booting multi user
<mjg>
i never got that far with my custom loloos before i got fed up :>
<epony>
and doom2 badge of honour too
<pbx_>
did a good long hyperfocus back in 2014-2015/last year of highschool
<mjg>
hm
<pbx_>
then got fed up with the amount of hard to squash bugs that had accumulated
<mjg>
makes me wonder, who started writing their custom os past being 24-ish years old
xenos1984 has quit [Read error: Connection reset by peer]
<pbx_>
largest one turned out to be an occasional 2 bit error in a DMA target buffer causing random corruptions
<epony>
btw, the vapourware list probably needs a mention of "remote" gaming systems (GaaS)
pbx_ is now known as pbx
<mjg>
if i hypethicallly could write bug-free code from now on, i still could not be arsed to write a kernel from scratch now
<pbx>
same, same
<epony>
yeah, unless it's a mini-micro-nano-pico-femto
<mjg>
ye a toy
<gog>
i will never write a kernel and i need to accept that
<epony>
let's just skip the millikernels
<pbx>
but it's a nice high level break from staring at CPU implementation hdl for a living
<zid>
Oh no, mjg is trying to escape from this bucket of rats
<zid>
someone stop him
<mjg>
zid: bro i'm n kernel for life
<zid>
phew
<mjg>
just not ones i wrote from scratch
<epony>
but hay, you can always work on pooling resources and tune / improve / rework existing "workable" and 'observable' (as in approachable scope) kernel projects
<mjg>
as much as i like messing with cpu in terms of perf, i detest fucking with configuring interrupts and so on
<mjg>
epony: or you can get a dayjob doing kernel work :-P
<mjg>
just sayin' it is an option
<epony>
yeah, it takes a special needs person to do that
<pbx>
trust me, multithreading locking stuff feels like childsplay compared to functional unit interactions in a big ooo cpu
<mjg>
thank you
<mjg>
that i do find plausible
<epony>
the best game in town is the schedulers "interchangeable" during runtime modularity
<epony>
if the packet filters can get it.. why not processes ;-) these days.. there are pause on hypervisors too
<mjg>
pbx: fwiw *locking* is easy, now fucking with memory barries is where it's at
<epony>
nesting schedulers ;-)
<mjg>
epony: well from what i hear sensible big.LITTLE scheduling is already a problem, so... :)
<epony>
someday we'll get standardisation on process data structures
<epony>
"SOON" (muahahahaha)
<epony>
portability is on "data structures" say object oriented programming languages (and we don't believe that)
<epony>
it's on bytecode, say the application virtual machines
<gog>
don't port software
<gog>
make incompatible things
<epony>
some distributed operating system vapours swear on (at) network protocols
<gog>
oh you better believe i'm against distribution
<epony>
but but but.. HPC come-on be a man about it!
<gog>
i will never be a man
<mjg>
common cat
<epony>
other systems claim it's the message passing and the partitioning of workload and run on clusters with portability by "networking" hardware (dense interconnects)
<kazinsal>
. o O ( fanfare for the common nyan )
<gog>
fiber optic interconnects
<gog>
the trick is not having to convert the optical to the electrical
<epony>
it's definitely also possible on algorithms, "some" standards, (almost none) data (serialisation and object / file / encapsuation) formats, network protocols (whoa there) and sometimes (mmm, nope) on application and system designs and computers hardware (could be but isn't)
xenos1984 has joined #osdev
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<epony>
so.. actual portability is: a dominant design ;-)
<gog>
we could return to the 80's and have a proliferation of incompatible systems
<epony>
with different word sizes (variable at best)
<gog>
yes
<epony>
and.. whatever random coice of signedness and endianness
<gog>
non-power of two word sizes
<pbx>
throw a few ternary systems in too for good measure
<epony>
(and different memory and cross machine buses)
<epony>
and a LISP CPU just in case
<epony>
time to mess up with them truth tables
<gog>
yes
<epony>
that's what we're going to get when a very complex and highly sophisticated hardaware uniform and standard system.. emulates primitive logic building blocks with mistakes to run a fertual pseudo-machine called "the neverhalting continuation engine"
<bslsk05>
en.wikipedia.org: Network scheduler - Wikipedia
<epony>
what do we call an killer-application that targets systems with special arrangements to facilitate monster applications with incorrect designs (an "animal farm" 1948 style)