vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<vin>
If there is a processor chip which supports no timmer interrupt but has 1000 cores per die (hypothetical) so appliiications can have dedicated cores specified to them rather than being time shared. A spin lock would do well becuase there will be no repeated cost of context switch or provides low latency response time. But why would a spin lock not do well on this hypothetical design?
<vin>
/s/or/and/g
tacco has quit [Remote host closed the connection]
<MelMalik>
A spin lock would create heat.
<MelMalik>
You need a cold lock to sleep the core, and an interrupt to wake it up.
<MelMalik>
Also, consumes power
<vin>
So it's just heat and power?
<clever>
in such a cpu design, upon failing a spinlock in userland, i would issue a futex syscall
<clever>
which would put the thread to sleep, and wait for an IPI signaling release of the lock
<clever>
that also relies on an atomic increment opcode, to let the other end know you want to be woken up
<clever>
my understanding of that api, is that userland will try to get the lock with atomic ops, and use futex to block upon failure
<vin>
So when would a spin lock fail? It keeps waiting on the resource until availaible right
<clever>
well, it would be less of a spinlock then
<clever>
more of a lock_try function
<clever>
but i have seen spinlocks that include a try function, for when you dont want to spin
<vin>
yea more like busy wait. So spin lock just tries a few iterations and sleeps if resource is not acquired?
<clever>
yeah
<clever>
arm and haskell also have a different approach to things
<clever>
with arm, you get a token from the cpu core, that says you own a given addr
<vin>
oh then power and temprature is not an issue with spin lock if it's only a few iterations
<clever>
then you do load/compute against the value
<clever>
then you do a "store only if i still own it" opcode
<clever>
arm never actually stalls or says no when you fail the lock
<clever>
it will instead say no, when you try to write the value back
ahlk has quit [Read error: Connection reset by peer]
<clever>
so if your read/modify/write contested with another core, it becomes a read/modify/abort
<clever>
and the routines around that, are responsible for trying again
ahlk has joined #osdev
<clever>
haskell has a similar mechanism in STM, where you read a sequence-counter for every variable you read as you compute an arbitrarily complex operation
<clever>
and every write, just stores them into a temp buffer
<clever>
then during commit, you grab a global mutex, check the sequence counters, and maybe commit
<vin>
So why would a failed spin lock do a syscall?
<clever>
so you can have the scheduler yield control to another task, or drop into a low-power state
<clever>
until somebody else releases the lock
<vin>
but in this chip processors aren't time shared so does it make sense to yeild control to another task?
<vin>
each thread had a dedicated processor
<clever>
you can still drop into a low-power state
<clever>
where you basically just shut off the clock for the core, and halt all state changes
<vin>
So the kernel itself is running on a bunch of dedicated cores where the user app communicate to it via some call api.
<clever>
in such a system, i would have the kernel and userland on the same core
<clever>
when you issue a syscall, the core just changes into kernel mode
<clever>
and while in kernel mode, it has the power to sleep until an irq happens
<vin>
can't clever, they can't be time shared because there is no timmer interrupt
<clever>
you dont need a timer interrupt to share it
<clever>
windows 3.11 never used timer interrupts for time-sharing
<clever>
it was 100% volentary
<vin>
I see.
<clever>
a thread only looses cpu when it chooses to give control back to the kernel
<clever>
and the same can be said about any thread on a real-time scheduler
<vin>
So one issue I can think of from our discussion is that a spin lock that can't be interrupted can end up being stuck on the core forever without making any progress and no way to recover it.
<clever>
yeah, so you would want to avoid using such locks
<MelMalik>
personally i would have interrupts on such a cpu
<vin>
haha yes
srjek has quit [Ping timeout: 268 seconds]
<MelMalik>
because not having interrupts means you can't reliably schedule more than, eh, 700 tasks at once
<vin>
Yes, this was just me thinking about concepts in different settings, not practical in any sense.
[itchyjunk] has quit [Read error: Connection reset by peer]
<geist>
if you wanted to build such a design you'd probably do some sort of hardware event style yield
<geist>
kinda like ARMs WFE/SEV but a bit smarter
<geist>
then your spinlocks dont spin, they check and then go into a sleep waiting for another core to signal the same address
dude12312414 has joined #osdev
eryjus has joined #osdev
<clever>
geist: yeah, if you had a way to target the SEV, you could do that far more efficiently
<clever>
how does SEV operate, when you have multiple guests under an EL2 hypervisor for example?
<geist>
arm64 actually does, it's implicit when you store to the address you had previously acquired an exclusive line to
dude12312414 has quit [Client Quit]
_eryjus has quit [Ping timeout: 260 seconds]
<geist>
caveats being that the size of the observation area is relatively large and defined per core
<geist>
though i think it's always a cache line practically speaking
<geist>
since that's really how it works: the cpu grabs the line exclusively and waits for another core to write to it, thus losing the exclusiveity
<geist>
that triggers an explicit local SEV to the core
<clever>
yeah, i read somewhere, that the load/store exclusive, expands the region up to a whole cache line
<clever>
but the api only garantees for the host-size word you targeted
<geist>
basically
<clever>
can the EL2 api entirely hide that your even running under a hypervisor?
<clever>
i can see how you might emulate all of the hw in a board, but masking any artifacts of the emulation would be tricky
ElectronApps has quit [Remote host closed the connection]
<geist>
there's some bits somewhere that control the scope of SEV/WFe i think
<geist>
like, wiether or not it's restricted to a single guest or not
<clever>
ahhh, thats what i was thinking of
bgs has quit [Ping timeout: 264 seconds]
bgs has joined #osdev
smeso has quit [Quit: smeso]
smeso has joined #osdev
mahmutov has quit [Ping timeout: 268 seconds]
Oli has quit [Quit: leaving]
ElectronApps has joined #osdev
__xor is now known as _xor
<nur>
the latest sigops newsletter I got is about graph computing
<nur>
I wonder how that fits into OS research
<klange>
sigops isn't actually about operating systems and I'm not sure it ever was
<bslsk05>
'USENIX ATC '21/OSDI '21 Joint Keynote Address-It's Time for Operating Systems to Rediscover Hardware' by USENIX (01:06:19)
<vin>
There are hardly any new OS designs and iimplementations being published in peer-reviewed avenues.
<kazinsal>
yeah, new designs are pretty rare because they're universally either not useful for anything other than as a tech demonstrator for "if we had 40x the computing power and quantum coprocessors this would be disruptive!" or something so inventive it wouldn't have any papers written about it until after it received a commercial release
<nur>
this didn't use to be the case
<vin>
kazinsal: in the talk Timothy argues the importance of OS desgined for modern SOCs forget quantum computers.
<vin>
what are your thoughts geist? I am interested in learning what motiviated you to start Fuchsia?
<geist>
well, i didn't start it, i was just working at the time
<geist>
more like being in the right place at the right time
<nur>
Tim Roscoe's talk reminded me of Rob Pike's "systems research is irrelevant" waaay back in 2000
<nur>
and many of the same things are still true
<nur>
hardware has changed/software is stagnant
<vin>
Oh I thought you started Zircon, sorry!
<geist>
well, i was there at the beginning but i didn't personally start it
<geist>
certainly dont have that kinda clout :)
<vin>
geist: Nevertheless, what was the motivation for the project? Any *specific* problems google was looking to solve?
<geist>
sadly those are precisely the things we aren't allowed to talk about
<geist>
i mean having a modern capability based design, etc is fairly obvious
<geist>
ie, build something from scratch with more modern security and compartmentalization from day 1
<vin>
No worries :) I expect to see it in OSDI/SOSP 4/5 years from now.
<geist>
hmm, whta are those?
<nur>
OS conferences I guess
<vin>
Yes
<kazinsal>
OSDI is the usenix OS conference iirc
<geist>
ah yeah
<nur>
SOSP is the ACM one
<geist>
probably worth doing some talks for that
<geist>
reminds me there was a fairly good paper written about the fuchsia security model recently that i was reading that was fairly good
<geist>
a bit inaccurate with the kernel but it was mostly talking about the component model in user space
<vin>
Most of google's work has been published after a while in these conferences. Like GFS, Borg, Map reduce, Colossus, etc
<bslsk05>
lwn.net: Fuchsia: a new operating system [LWN.net]
<nur>
some of it already outdated :-|
<vin>
klange: maybe you should! A talk at strangeloop would be a good start.
<nur>
like "magenta" instead of "zircon"
<geist>
hehyeah
<geist>
long live magenta!
<klange>
I did do a talk once. One of my previous employers did regular internal free-topic tech talk sessions and I did a whole deep dive "What happens when..." thing.
<klange>
I need to redo that slide deck, since that was 2015 when I was still using newlib.
<Mutabah>
You had a video of that, right?
<klange>
Yeah should still be up on my YouTube but might be unlisted just because I'm terribly embrassed by it.
<geist>
yeah i did exactly one talk in front of 1000 people and i have to say it was a bit terrifying
<klange>
Giving that talk is actually what pushed me to do the NIH thing.
<geist>
surprisingly less so leading up to it, i thought i had it nailed
<geist>
but i started to lock up half way through it
<geist>
but thankfully someone else was co-presenting and could kick me along
<klange>
Because one of my coworkers - who had previously worked on NT before joining us - badgered me about newlib and whatnot.
<klange>
ToaruOS is 100% built on spite.
<geist>
so. bummer that happened, since it kinda crushed my confidence in things like that in the future
<kazinsal>
yeah, I've done a couple internal presentations on like hypervisor architecture and stuff but only to the six or seven people in the company who find that kind of deep nerd stuff interesting
<geist>
yah i can talk to folks i know without much trouble
<kazinsal>
eventually I'd like to end up with an OS project I can give a talk about, but I think I also said a few years ago that I was aiming to have a release out by now, and well... ;)
<geist>
yeah same
<kazinsal>
I look forward to having something to give a talk about in 2028
<nur>
me too, but then "getting a real job" got in the way
<nur>
I now write customer service chatbots for Dell :-|
<zid>
Finally someone who can fix my printer
<kazinsal>
entertainingly I got my current job in part because of my earlier osdev stuff. not because it's relevant to my job, but because it was so bafflingly nerdy and clearly a tech passion project
<nur>
zid, technically I would write you a bot that could forward you to someone who can fix your printer
<kazinsal>
and also my director and I are both guitar nerds so that helped
<klange>
I have a guitar now.
<nur>
although can printers be fixed really? I feel they're cursed
<nur>
I wonder what writing a printer driver feels like
<zid>
printers are disposable items built around ink cartridges
<klange>
This would not really be news except it was a preorder for a collab guitar that I placed nearly a year ago and it was delayed so the fact that it _finally_ arrived...
<nur>
I guess I'll find out once I get to the "printer" part of the osdev exercise
<klange>
Printer drivers are a bit of a misnomer. It's almost all document conversion, either to postscript or PDF.
<zid>
If you only deal with networky printers that talk postscript I'm sure it's easy, it's the 'winmodem' printers that never work
<nur>
cursed I say
<zid>
where the drivers have to control the motors or whatever
<klange>
And then you either blat it out over some serial interface or throw it at an HTTP endpoint.
<kazinsal>
see, that's why I'm writing a network operating system. no one ever expects their router to have printer drivers ;)
<klange>
I'm not aware of any of those that still exist. Everything is a PostScript or PDF printer these days, and CUPS profiles almost entirely consist of names for knobs.
<zid>
In other words, only ever do osdev targetting precisely the easiest era of the tech you're talking about
<klange>
This is why I target VMs. No one is going to print from their VM!
<nur>
well, to a network printer :)
ravan has quit [Ping timeout: 260 seconds]
MarchHare has quit [Quit: Leaving]
pretty_dumm_guy has joined #osdev
C-Man has quit [Ping timeout: 268 seconds]
ElectronApps has joined #osdev
dormito has quit [Quit: WeeChat 3.3]
bokfink has joined #osdev
wolfshappen has quit [Ping timeout: 260 seconds]
wolfshappen_ has joined #osdev
GeDaMo has joined #osdev
Arthuria has joined #osdev
Arthuria has quit [Remote host closed the connection]
eryjus has quit [Read error: Connection reset by peer]
eryjus has joined #osdev
ahalaney has quit [Quit: Leaving]
_eryjus has quit [Ping timeout: 264 seconds]
MelMalik is now known as AmyMalik
mjg has joined #osdev
vdamewood has joined #osdev
[itchyjunk] has joined #osdev
heat has quit [Remote host closed the connection]
niedzejkob[m] has joined #osdev
<niedzejkob[m]>
TIL, from reading the sectorlisp code, that apparently BIOSes load the MBR at 0x600 too. Is this described anywhere?
sprock has joined #osdev
<kazinsal>
never seen that behaviour before
<zid>
isn't that inside the IVT
<zid>
hmm I guess that might stop at 0x400 depending on whether I can count or not
<zid>
It's possible that's the disk buffer location some random bios uses, and copies it to 7c00 before it runs it after checking the tag and stuff I guess
<clever>
i have heard that some bios will jump to something like 0:7c00, while others jump to 7c0:0 ? something like that
<clever>
and it can screw with programs that assume the segment reg when doing absolute jumps
<zid>
they're the same linear address
<clever>
exactly
<zid>
0x600 is definitely not
<clever>
but if you jump to CS:10, you wont get the same linear addr
<clever>
because the CS differs
<kazinsal>
anything since like, the late 90s shouuuuuuuld use 0000:7C00
cooligans has joined #osdev
mctpyt has quit [Ping timeout: 260 seconds]
<zid>
My 100% top guess is that it's a disk buffer used by possibly some common early bios
<zid>
it definitely isn't standard
<kazinsal>
CS=0 IP=7C00 is specifically defined in the BIOS Boot Specification from 1996 iirc