channel logs for 2004 - 2010 are archived at http://tunes.org/~nef/logs/old/ ·· can't be searched

#osdev2 = #osdev @ Libera from 23may2021 to present

#osdev @ OPN/FreeNode from 3apr2001 to 23may2021

all other channels are on OPN/FreeNode from 2004 to present

http://bespin.org/~qz/search/?view=1&c=osdev&y=20&m=8&d=4

Tuesday, 4 August 2020

01:01:02 <ronsor> what even was this? https://forum.osdev.org/viewtopic.php?f=2&t=37012
01:01:03 <bslsk05> ​forum.osdev.org: OSDev.org • View topic - OS Community. Read this. ArgonOS cancelled.
01:01:36 <geist> huh. beats me
01:02:02 <Mutabah> Joined three weeks ago, 14 posts...
01:02:39 <Mutabah> Oh, wait, that was their first post...
01:02:47 <geist> heh yeah
01:04:27 <Mutabah> Ah, the OP was edited, see "Arakis"'s post on page 2 for the original
01:04:57 <doug16k> delusions of grandeur
01:05:11 <doug16k> that's my medical opinion, lol
01:05:41 <Mutabah> My guess: Overconfident start, then massive backpedalling
01:06:06 <Mutabah> I'd consider locking the thread, but it's been over a week
01:06:26 <ronsor> holy crap
01:06:29 <ronsor> that's kinda hilarious
01:07:18 <doug16k> everyone is going to have to completely redo their schedule, since he cancelled it
01:07:46 <ronsor> it's very inconvenient. the schedule must be reworked.
01:12:22 <geist> you mean all of the people that were working on it?
01:12:31 <doug16k> no all of us
01:12:39 <doug16k> everyone
01:12:47 <geist> oh!
01:13:56 <ronsor> so terribly inconvenient
01:15:06 <doug16k> some people think that you just describe a design that is awesome, and you should get the majority of the credit you'd get for actually implementing the idea
01:15:33 <doug16k> as if you get credit for the idea of a plane that goes 6000km/h at 10000ft, without being the person that figures out how to not melt
01:22:30 <ronsor> indeed. they think they have the ultimate idea, then expect people that actually know what they're doing to drop everything to work on it
01:51:30 <geist> yah if they had come here it'd have been like the 40th time i've seen something ilke that over the years
01:51:46 <geist> someone comes in saying that everyone should help them do their big thing
01:52:01 <geist> obviously no one ever does, and it never goes anywhere, but i try to not discourage them too much
01:52:26 <geist> more than once they've come back a few years later a bit more knowledgable and wiser
01:57:43 <kingoffrance> eh, im gonna go with opposite diagnosis: lack of grand idea, nothing to center everything else around :/ IMO you need that more when you dont know what you are doing, because you need something "solid" that everything can be "in terms of" or otherwise be leading up to
01:58:56 <kingoffrance> i guess, i see nothing either "vaguely grand" or particularly minutely specifically "unique"
01:59:16 <geist> right, i mean i dont discourage them from giving up osdev, but i try to gently direct them towards something more concrete
01:59:46 <kingoffrance> yeah :/ im all for "im doing this to learn" but you cant expect world to jump in
01:59:53 <geist> right
02:00:20 <kingoffrance> and that disappears when you dont want to do the work to learn/code part :/
02:00:56 <geist> exactly, that's why i was trying to nudge that out of stuff_is a while ago
02:01:27 <kingoffrance> im a total noob, but i always ask ppl "what are your goals for your os?"
02:02:20 <kingoffrance> "if you dont know where you are giong, any road will take you there"
02:06:46 <geist> my experience is absolutely 100% of the people that i've seen here over the last 20 years that want to write an OS to replace windows/linux/etc fail
02:07:16 <geist> like, there's no path forward there to winning. you will not just design and implement something 'better' that people want to use
02:07:30 <geist> but... if you're interested in learning, trying some ideas, having some fun, etc you can get far
02:07:59 <geist> doesn't mean you dont have goals, but you set your goals based on progress along your own path, not in opposition to something else
02:12:32 <kingoffrance> ^^^ yes
02:13:44 <kingoffrance> put another way: you have to understand something sufficiently first to spoof or satire it :)
02:13:53 <kingoffrance> properly, anyways
02:15:38 <geist> yah and if you understood something that exists sufficiently well then you probably understand the scope of the project
02:15:47 <geist> and then you'd also probably not try to set out to replace it
02:19:09 <geist> hmm, this is interesting
02:23:00 <kingoffrance> im very much in favor of grand ideas, but in the sense of, that hopefully helps select other components i.e. narrow them down from x choices where it may not seem there is any reason to favor one decision over the other, but then hopefully you choose the thing that meshes better with what your other stuff is doing ; grand idea IMO should help you narrow other things down and every decision is "does this help/hinder/neither way my g
02:23:01 <kingoffrance> rand idea?" -- so, you need geist-like discipline :)
02:23:54 <kingoffrance> its supposed to help you get more concrete IMO
02:38:32 <geist> yah though i should object that i have no discipline
02:38:52 <geist> i've only done things by having been around a while and having a fairly one track mind (OS kernels)
02:39:01 <geist> there are folks with far more discipline than I :)
02:39:51 <kingoffrance> eh, one track mind, same thing on another plane if you prefer :)
02:40:26 <kingoffrance> specialization
02:42:54 <geist> yep
02:45:36 <kingoffrance> i guess i go down many rabbit holes/ "side quests" but only if they dont conflict with grand ideas
02:48:04 <geist> yah last few years i've spent most of my hobby time filling my brain with more esoteric hardware/platform stuff instead of actually accomplishing anything
02:48:12 <geist> hence all the talking about ACPI and VAX and etc etc
03:24:16 <kingoffrance> yeah and then you noticed m68k might have been vax inspired :) funny how that works :)
03:24:23 <kingoffrance> the past shows up in strange ways in the present :)
03:24:48 <kingoffrance> someone said that other day anyways
03:45:27 <geist> kingoffrance: yeah was probably me
03:45:37 <geist> does remind me, i should really sit down and hack on 68k some day
03:45:47 <geist> i even have one wired up on a breadboard
03:47:20 <zid> morning, we up to anything fun?
03:47:23 <doug16k> the thing has a primitive microop cache (only works for one instruction followed by decrement and branch). that blows me away that they did that way back then.
03:48:03 <doug16k> microop cache is a stretch. I mean primitive equivalent of modern microop cache
03:50:13 <doug16k> I love it when hardware bypasses instruction decode sometimes
03:52:22 <doug16k> and very cool that you can tell from outside the cpu whether it is an opcode, data, or page table memory access
03:55:21 <geist> yah plus things like cmp/branch being fused i think were pretty early stuff
03:56:45 <zid> one of the surprising thing to me was the littke instruction fetch buffer on the 8086
03:56:54 <zid> pretty damn early
03:57:28 <geist> yah that was a real selling item on 8088 and 8086
03:58:06 <geist> also back then i think the longest possible instruction was 6 bytes, so it just had a 6 byte holding register
03:58:23 <geist> or really 3 16 bit registers that it filled 16bits at a time in 8086
03:58:56 <geist> http://www.righto.com/2020/07/the-intel-8086-processors-registers.html blabs about it a bit
03:58:57 <bslsk05> ​www.righto.com: The Intel 8086 processor's registers: from chip to transistors
03:59:25 <geist> also kinda surprising that 8088 and 8086 was a different die, since he mentions that the instruction buffer was implemented slightly differently on 8088 because it could only fill it 8 bits at a time
04:00:37 <geist> also neat that he talks about the 7 'upper registers' which are basically 5 16 bit segment registers + 2 internals
04:00:53 <geist> very multi ported since they're accessed on every instruction one way or another
04:05:15 <geist> i wonder if the 6 byte instructoin queue actually shifted down as it filled or it was a head/tail pointer style thing
04:05:44 <geist> i'm guessing the former since that would make the decode logic simpler. shift through the instruction, and on particular phasese of the instruction latch the parts you need maybe
04:06:06 <geist> i wonder f you stare at the ISA it actually makes sense based on decoding that way. at least with instructions of that era
04:09:26 <zid> I'd be surprised if there was an ISA a shifter didn't work nicely for to be fair
04:09:27 <geist> well, i mean i guess it sort of intrinsically does, except for prefix bytes that modify opcodes that come later, but you can just cache the flags the prefix means
04:09:45 <geist> vs something like say a 4 byte data word coming first, then an opcode byte after it tat says 'oh that 4 byte word you just read, that was data'
04:10:19 <zid> exactly why, nobody encodes instructions anything but opcode operands
04:10:21 <geist> it's generally assumed that you read opcode + modifier bytes first beforegetting to data. it's just x86 is not particular clearly about it
04:11:58 <geist> something like vax or 68k is much cleaner about it, but fundamentally it's the same design: opcode + (optional) argument modifiers + argument data
04:12:47 <geist> but they dont do the prefix nonsense, which i think is largely a x86 invention
04:13:05 <geist> though other arches have 'escape' opcodes that then lead to additional opcode space
04:13:22 <zid> even gameboy has a prefix byte, to be fair
04:13:34 <geist> sort of. was gonna say that z80 kinda does y eah
04:13:36 <zid> it's not super strange in a variable width encoding
04:13:48 <geist> that's either a prefix byte or an escape depending on your point of view
04:14:11 <zid> I think it's more a prefix bit, but yo ucan't have a 9 bit byte just for one instruction :P
04:14:13 <geist> but since if you squint at it it only really modifies the next instruction in a fairly regular way (i think most of the time) you can consider it a prefix modifier
04:14:25 <zid> 0xCB 0xxx encodes every bit-op the cpu does
04:14:29 <zid> 100% packed, no waste
04:14:36 <geist> but i think there are some places where cb and whatnot modifies the next opcode in a non regular way
04:14:39 <zid> so there has to be *some* bit telling you what that xx byte is
04:14:45 <geist> in which case it's more of a escape
04:15:09 <geist> 6800 and 6809 definitely have escape bytes that just open up new space
04:15:12 <geist> as does VAX for sure
04:16:55 <geist> dunno about 68k. 68k uses 16bit opcodes, so i think they just had enough to encode everything
04:17:13 <zid> at the end of the day, all this is ad-hoc based on what fits, what you want, etc
04:17:25 <zid> nobody's working to make a "master planned" cpu from the outset
04:17:38 <zid> where they use every single bit as efficiently as possible, with a 10 year lead time on the deisgn etc
04:17:51 <zid> it's some guys with some pencils trying to make enough nice things fit into the gaps to be a useful cpu
04:18:08 <geist> http://goldencrystal.free.fr/M68kOpcodes-v2.3.pdf seems to be pretty clean
04:18:41 <geist> well... you say that and i think 68k was a pretty clean master planned thing, for at least a 10-20 year window (wasn't planned on 64bit extension, etc)
04:18:44 <geist> as is riscv
04:18:57 <zid> riscv gets updates and patches all the time though
04:19:03 <zid> and has gaps etc
04:19:05 <geist> but it's very well planned out
04:19:10 <zid> I'm not saying nobody planned it
04:19:11 <geist> as in the gaps are planned from the start
04:19:15 <zid> but until you implement it and get stuck in etc
04:19:21 <geist> as in 'future extension X goes here' kinda stuff
04:19:22 <zid> you don't really know what it is you actually wanted or needed
04:19:36 <geist> so that they can explicitly design gaps for things like 'this is where we promise to never use it officially'
04:19:44 <geist> for vendor specific extensions and whatnot
04:19:45 <zid> "Oh turns out it'd be REALLY handy if actually, we swapped the encoding for NOT and AND, so that I have this wire over here instead" bla blah
04:19:49 <zid> youd on't find out until you make it
04:20:02 <geist> yah well, in the case of riscv they have 'frozen' the base ISA
04:20:11 <geist> which means precisely that. it's not ever okay to change it
04:20:28 <zid> which is how you end up with weirdness in designs 20 years on
04:20:33 <geist> ie, they've had their 5 or 8 years to figure it out so they can freeze it
04:20:54 <geist> true. their escape there is they've planned on longer instruction words
04:21:02 <geist> 48, 64, all the way up through 128 bit i think
04:21:12 <geist> and those spaces are open as of now
04:21:18 <zid> That "Oh I wish we swapped NOT and AND, shit" thing you can't move just stays like it, and hat bodge gate you added stays forever :P
04:21:20 <adu> I thought it was variable length
04:21:28 <zid> that bodge gate turns into how we see the A20 gate today
04:21:46 <geist> adu: it is, yes. though nothing > 32bit is i think specced out, except how to encode that this is a >32bit word
04:22:15 <zid> Start with a design, fudge it a little to actually implement it performantly, let 20 years of microevolution happen without any bodyplan changes, realize you have a small mess that is pretty good still
04:22:19 <zid> repeat for next ISA
04:22:22 <geist> but the pattern for encoding the length of the instruction is defined, up through 128 bit i think
04:22:32 <kingoffrance> thats how i feel about posix. do i want to be incompatible? no. do i think i can do better? no. OTOH, honestly, they just looked at what x os *were already doing*, chose a subset to "standardize" on, and *after the fact implementations existed* then it became standard from what i see (not all one way or the other, but historically i think the "weight" is on that POV)
04:23:06 <geist> right and with ISAs it's almost always never okay to just arbitraroily change things
04:23:08 <kingoffrance> with some renamings and such i believe too
04:23:12 <zid> Right it isn't specific to CPUs
04:23:19 <zid> Basically all of humanity works like this all over
04:23:19 <geist> you can end up with things like PIC where there are like 5 different ISAs all called PIC I think
04:23:27 <zid> road design in cities woud be a good parallel
04:23:30 <geist> but you do what you can
04:23:44 <geist> i think riscv at least has made a darn good stab at building a base extensible thing for 10-20 years
04:23:49 <geist> as did motorola with 68k
04:23:52 <zid> "this road sucks, but we can't just move it, people use it, try adding traffic easement bits to the sides.." blah blah
04:24:01 <geist> things like x86 had no future planning at all so it turned into an encoding disaster
04:24:19 <geist> arm32 as well, it got really really messy
04:24:22 <zid> the encoding disaster isn't really a problem though, look at english vs latin :P
04:24:30 <geist> which is why they restarted with arm64 and did a fairly clean opcode layout
04:24:43 <geist> well, it *is* you just dont know any better
04:24:46 <zid> x86 would have struggled to future plan anything
04:24:52 <doug16k> x86 code is compact though
04:24:59 <zid> so is english
04:25:04 <geist> as in, yah english sucks and maybe we'd all be better off if we invested in esperanto but you dont know nor never will
04:25:15 <geist> *except* that you can still run the math and figure out how much better it'd be
04:25:22 <geist> doug16k: oh sure, but you could definitely do much better
04:25:29 <zid> turns out it's regular, boring, and lacks things like rapid evolution of slang etc
04:25:47 <zid> x86 is definitely some guy's modded car
04:25:51 <geist> it just happens to be compact because all in all bytewise based CISC machines are pretty dense, but x86 is not particularly efficient at packing stuff in
04:26:27 <geist> things like rex prefix and whatnot and a bunch of random seldom used one byte opcodes hanging around using up space
04:26:40 <zid> I like the idea of the planning committe for the 8080 being told they need to support 512 bit vector operations at 5GHz in their design, for the future
04:28:28 <kingoffrance> lol
04:28:47 <kingoffrance> well im sure if you guaranteed them funding theyd jump on it
04:29:04 <zid> It's just impossible nonsense though
04:29:09 <kingoffrance> thats the thing -- they have to do all this, try to get to market on time, and try to be profitable too
04:29:12 <kingoffrance> someone has to anyways
04:29:44 <zid> If you were to design a plan to get from the 8080 to 'a modern cisc' where you have to do a USEFUL release every few years, you wouldn't end up far from where we are now
04:29:47 <doug16k> 256 is wide enough
04:29:49 <zid> add an fpu, add levels of sse, etc
04:30:09 <zid> upgrade from 16 to 32, upgrade from 32 to 64
04:30:21 <doug16k> 256 is half of a cache line
04:30:27 <doug16k> can do two loads at once
04:30:36 <geist> i do think that doing a bitness upgrade is worth a redesign if you didn't have it in from the get go
04:30:40 <doug16k> entire cache line per cycle
04:30:47 <adu> no one will ever need float128x1024 vector pipelines
04:30:58 <geist> x86 shoulnd't have done it, and even risc machines have a tough time, though it's generally fairly easy to do
04:31:13 <geist> riscv has some tentative stuff for 128 bit, but nothing in stone yet, more like designing out how it'd probably work
04:31:23 <geist> arm32 tey didn't try, they just started over with arm64
04:31:44 <zid> I imagine the 186 was already a 'try set the groundwork in the design for a 32bit switch'
04:31:45 <geist> POWER was always 64bit, as was alpha
04:32:22 <zid> problem with the mode switch changing the ISA
04:32:26 <zid> is that you have to duplicate a LOT of stuff
04:32:38 <doug16k> 186 was only used for embedded use, wasn't PC compatible
04:32:40 <zid> instead of just not enabling a bunch of high bits (eax and ax)
04:32:59 <geist> right, that's why risc machines have it pretty easy, since if you set the rules in advance for what you do wit the top of the register you can usually design the ISA to be forward compatible within reasons
04:33:14 <doug16k> they did the interrupt controller incompatible in 186 IIRC
04:33:15 <geist> ie, 32bit risc code can just pretend the top of the register is't there and do what it needs to do
04:33:26 <zid> and all your code density is now out of the window, because all your 1 byte operations target the wrong regs (ax not eax)
04:33:27 <geist> stuff just gets shifted out into the void, and maybe bits are there
04:33:39 <zid> so now you, very reasonablly, switch them to target eax by default
04:33:50 <zid> and move the ax encoding elsewhere (a prefix, for example)
04:33:55 <zid> it all makes sense in terms of evolutionary change
04:34:01 <zid> there's nothing in x86 that makes me go "what, the fuck?"
04:34:36 <geist> there was a lot of switcharoo with the 32bit extensions on x86. somewhat to fix the really limited addressing modes on 8086
04:34:49 <doug16k> the descriptor cache "big" bit for CS makes it assume 32 bit
04:34:53 <geist> kinda like x86-64 they added some more regularity to the way mod r/m and whatnot decodes with 32bit
04:35:06 <zid> It's still not too disimmilar though in terms of encoding, just more and better
04:35:17 <zid> [si+bx] etc turned into its own byte that can do basically everything
04:35:21 <geist> i didn't realize how crummy the addressing modes were on 8086 until doug16k pointed it out the other day
04:35:57 <doug16k> yeah, very little freedom. compilers can hardly even have a register allocator
04:36:01 <geist> but strictly speaking those are not 'clean' extensions. that's a mode switch that then causes stuff to get decoded differently
04:37:01 <geist> an alternate exeample is the 68k, which was introduced in 1980. 16bit machine with a 32bit ISA
04:37:12 <geist> as in they designed it to be extended to 32bit, which it was almost immediately
04:37:41 <zid> I think people too often think of x86 as a 'carte blanche extension to earlier cpus' when really it was a multi-hundred person multi-year project to try, in the goal of making a real cpu you can actually make and sell, re-purpose of as much silicon as possible to implement two concurrent ISAs
04:38:00 <doug16k> i386 was a huge step forward
04:38:01 <geist> oh sure. that's why it's so interesting
04:38:07 <geist> it's a real hot mess, but interesting anyway
04:38:19 <doug16k> 80386 trounced 286 and previous
04:38:23 <geist> keeps folks like us interested anyway
04:38:28 <zid> It isn't a hot mess though, it's actually incredibly well done, if you go beyond the surface level
04:38:46 <geist> well.. that's kinda debatable, but i get your point
04:39:12 <geist> implementation details of current physical designs could be applied to any ISA, they're not really an x86 specific thing
04:39:25 <geist> if anything they're in *spite* of x86. as in there's a lot of effort and silicon there to make it work
04:39:49 <geist> but yes the implementations of modern x86s are amazing for sure
04:40:05 <doug16k> yeah it basically transforms the ISA into something else, and that something else largely determines the performance
04:40:40 <geist> plus not just ISA. things like a strong memory model, which is very hard to implement
04:40:58 <zid> I dread to think where we'd be without x86's incredibly strong memory model tbh
04:41:00 <geist> hence why almost everything else goes for a weak memory model and makes it a programming problem
04:41:03 <zid> if everything was an alpha I'd be upset
04:41:09 <geist> well, i know what it is, it's arm and risc
04:41:35 <geist> and you get by. it's a pain but pretty solvable
04:42:17 <geist> it's all tradeoffs. the hardest part to grok on ARM is the memory model
04:42:19 <doug16k> don't you think we should be moving toward strong model? to reduce potential bugs
04:42:26 <doug16k> in the future I mean
04:42:52 <geist> dunno! unclear how many bugs are WMM, since most WMM bugs are just badly written code
04:42:55 <geist> or code written assuming x86
04:43:08 <doug16k> shouldn't we be making it more difficult for bugs to go unnoticed?
04:43:12 <zid> Part of why x86 is so enourmously complex is actual user demands of the platform have all piled up, fpu/3dnow/sse/PAE/PCI/SMP/SMT/etc
04:43:14 <doug16k> not less difficult?
04:43:18 <geist> so it's a chicken and egg thing. if we weren't porting so much code from x86 maybe it would be less of a problem. and i honestlyd dunno how much of a problem it is in practice
04:43:21 <zid> If we also had to deal with a weak memory model? blerrrgh
04:43:34 <zid> people would have demanded a stronger model regardless imo
04:43:46 <zid> no matter WHICH cpu became the de-facto desktop chip, it would have ended up with a strong memory model
04:44:12 <geist> dunno. not sure why you think 'people' would have been able to demand anything that a vendor comes up with
04:44:19 <geist> they come up with what they want and software folks adapt
04:44:20 <zid> because the chips have to sell
04:44:31 <zid> intel didn't pick features out of a hat
04:44:32 <geist> as if you've ever had a real choice
04:44:41 <geist> well maybe you did in the 80s i guess
04:44:51 <zid> You don't think they added hyper-v etc because of massive customers like datacenters demanding it?
04:44:57 <geist> but joe user doesn't give a crap what the ISA is or what the memory model is
04:45:20 <zid> they added mmx specifically to put "look how good we are at graphics and audio" on the box, etc
04:45:23 <Colin_M_> I think they added that as a marketing-driven feature so they could say "look at what we can do in a data centre over the competitor"
04:45:24 <zid> not because the engineers wanted it
04:45:29 <geist> sure, but fundamental things like the memory model are not usually a thing you fiddle with as a feature
04:45:51 <doug16k> games were a reason to buy good machines though
04:45:57 <zid> "Look how easy we are to program threaded programs on"
04:46:05 <geist> and funny, x86's weak memory model instructions are in the SSE space
04:46:10 <zid> is absolutely a meeting they had with a client at some point
04:46:13 <doug16k> software rendering is hard on a slow cpu with really slow framebuffer writes
04:46:17 <geist> AVX maybe to? I dunno if there are any there
04:46:30 <zid> if intel weren't around we'd be using m68ks with strong memory models and weird 64bit extensions with 256bit sse
04:46:45 <zid> I don't think there's any escaping it
04:46:48 <geist> yah, and i'd like to think motorola would have done a better job extending it
04:47:14 <geist> but who knows. also remember the 64bit stuff wasn't intel, so on top of that x86 was extended across multiple competing companies
04:47:17 <geist> which is even more disjoint
04:47:32 <adu> what do you mean by weak memory?
04:47:38 <zid> model
04:47:39 <adu> is that like more caching?
04:47:40 <zid> weak memory-model
04:47:52 <adu> what do you mean by weak memory-model?
04:48:03 <zid> means things like whether writes are visible between cores in the order they happened
04:48:17 <doug16k> adu, weak means the order you write things into memory isn't necessarily the order that those changes appear to other cpus/agents
04:48:18 <zid> basically how much locking you need when writting threaded programs :P
04:48:18 <geist> it's a fairly complicated subject, and i ddefinitely recommend grepping around the internet a bit but yah the TL;DR is what zid said
04:48:34 <zid> https://en.wikipedia.org/wiki/Memory_ordering#In_symmetric_multiprocessing_(SMP)_microprocessor_systems
04:48:34 <bslsk05> ​en.wikipedia.org: Memory ordering - Wikipedia
04:49:06 <doug16k> and the order you read things isn't necessarily the order that they are read
04:49:14 <zid> Itanium and alpha? Good luck writing anything threaded without introducing 400 memory barriers by hand. AMD64? Cpu does almost all of it for you.
04:49:20 <geist> thankfully lots of languages have recognized that this is a thing to think about and are either specifying it or providing mechanism for it
04:49:33 <geist> zid: honestly it's not that bad
04:49:52 <geist> i think you're a bit straw manning that one a bit
04:50:04 <zid> geist: Because we have people like the lkml arguing for weaks on what the primitives should be and providing them as syscalls etc
04:50:14 <zid> weeks*
04:50:23 <geist> sure. that's their job, so everyone else doesn't have to
04:50:30 <geist> and the everyone else is really what matters
04:50:46 <zid> what was it that ballmer said, develoeprs developers developers developers? :P
04:51:01 <geist> developers developers developers developers
04:51:02 <geist> indeed.
04:51:09 <zid> if the devs don't want to write threading code on your machine, your machine isn't threaded
04:51:15 <kingoffrance> some developers are more equal than others :)
04:51:24 <geist> sure. anyway, threaded code is
04:51:37 <zid> if lkml decided blackfin was too hard to maintain, it doesn't get linux support and your entire ISA is dead
04:51:37 <geist> 'dangerous' anyway. WMM is just another aspect of it
04:51:41 <adu> I'm aware that Java has one of those specs
04:52:07 <geist> also yes, lots of higher level languages make it moot by mandating a particular memory model, and then dealing with it under the hood
04:52:18 <zid> There's a platonic ideal ISA that developers want to work on, and it's basically "It's the C abstract machine with a strong memory model"
04:52:46 <doug16k> java volatile tries to deal with memory ordering
04:52:52 <geist> true, though if you start to take advantage of the fact that things are strongly ordered by not locking stuff properly, you're basiclaly asking for it
04:53:12 <geist> but it's kinda circular logic at that point
04:53:21 <geist> as in you have to lock stuff for a variety of reasons, one of which is memory model
04:53:43 <geist> but that's because locks also have implicit memory barriers in them
04:54:11 <geist> so that the existing model of using locks and serialization to deal with multiple threads also works on SMP machines and ones with WMM
04:54:59 <doug16k> one might argue that it's better to get bad data in weak model so you notice when you forgot to acquire the lock
04:55:18 <adu> I used to do some multi-processing in python, but it never really worked right because of the GIL
04:55:41 <kingoffrance> freebsd used to call it GIANT i beleive
04:56:02 <geist> doug16k: yah
04:56:40 <kingoffrance> ruby too has a giant lock
04:56:47 <kingoffrance> or did
04:57:31 <adu> if I ever really wanted to do that multi-processing I'd probably re-implement the task with kubeless or tekton
04:57:34 <kingoffrance> giant mightve been something else, but hence dragonfly
04:59:22 <siberianascii> good morning
05:01:43 <geist> will be interesting to see many more developers exposed to WMM via arm based macbooks
05:02:04 <siberianascii> sure
05:02:04 <geist> but, presumably apple will try to drive people towards their language
05:02:16 <geist> though i haven't looked into the memory model it defines
05:03:00 <adu> what's so dangerous about it?
05:03:35 <geist> just general hazards that can result from the assumption that things are strongly ordered
05:03:53 <geist> it's a bit of a brain teaser but it definitely expands the possibilities of bad synchoniation between threads
05:04:39 <adu> I think the assumption is the dangerous part, I don't see how WMM is bad
05:04:51 <adu> it's the person doing the assuming that's bad
05:05:08 <zid> a WMM isn't bad, but it's not developer friendly
05:05:17 <geist> not that strong memory model makes data races go away either
05:05:23 <zid> Like not having hardware div, you can absolutely program without it, but you don't want to :P
05:05:26 <siberianascii> "person's" are the weakest link in every system my friend adu
05:05:27 <geist> it just makes certain classes of them go away vs weak
05:05:45 <bcos> You put cereal in your bowl, then put the cereal box away and start putting milk in your bowl. Then you look at the bowl and there's milk and no cereal. It's all the bowl's fault.
05:06:06 <adu> but I don't understand what's so different about ARM, do atomic primitives not exist or something?
05:06:24 <geist> adu: no, not at all, in fact the atomics are quite nice on ARM
05:06:43 <geist> it's that standard memory accesses a given cpu does can happen in arbitrary order relative to another cpu
05:07:12 <geist> so the classic example is if i write to two global variables: a = 1 b = 2 in order, even if they're volatile
05:07:30 <geist> another cpu may not observe a before b, or b before a, or either of them relative to anything else
05:07:48 <geist> *until* the first cpu puts in some sort of memory barrier that enforces that things were committed to the cache
05:08:24 <geist> note this isn't that the cpus are not cache coherent, they are. but the cpu is free to reorder memory accesses as it sees fit, as long as it appears in program order *to that cpu*
05:08:34 <geist> there's no consideration for how external cpus would see the accesses
05:08:55 <zid> "order they happened to the DRAM" vs "Order they happened in the program" may not be the same, basically
05:09:00 <zid> because of things like speculation
05:09:01 <geist> right
05:09:32 <geist> and in this case 'dram' is a more loose term of 'from the point of view of external observers as they see the same 'memory''
05:09:39 <zid> The simple example of where it actually *matters* is something like "take lock, update counter"
05:09:57 <zid> Without the barrier you might see "COunter gets corrupted out of nowhere, then the lock is taken"
05:10:35 <uplime> do you have to write special code for arm targets to guard against that?
05:10:59 <geist> correct. it's called a memory barrier
05:11:05 <maurer> You need to write it for all targets, ARM targets are just more likely to have it happen.
05:11:28 <geist> the simplest thing you do is a 'dmb' instruction. it says 'all pending memory accesses before and after this instruction happen on either side of the fence'
05:11:28 <uplime> ah, neat
05:11:40 * uplime jumps down the rabbit hole
05:11:50 <geist> but there are all these more subtle variants of it and ways to attach it to load stores and atomic operations and wahtnot on modern arm (arm64)
05:12:38 <geist> and most of this is handled inside things like your mutex functions. there will be barriers implicit in there that make it such that things before and after the lock acquisition and release happened on either side of them
05:12:45 <geist> and that deals with 90% of it right there
05:12:46 <maurer> https://arxiv.org/pdf/1904.05389.pdf is a pretty comprehensive summary (you can ignore the RMC they present and just read the background. RMC is cool but not in real world use)
05:13:06 <geist> also atomic operations are usually full barrier on ARM, though you can do weakly ordered atomics which are pretty neat, and not a thing you can do on x86
05:13:36 <maurer> Hm nevermind, evidently the conference form of that paper dropped a lot of the background to fit in page limit :/
05:13:46 <maurer> I wonder if the full version is still hanging around somewhere
05:14:15 <geist> weakly ordered atomics are neat, great for just bumping some global counter. they can happen in any order relative to other load/stores around them so it doesn't serialize memory accesses
05:14:25 <geist> but its still guaranteed to actually be atomic
05:15:15 * kingoffrance adds barrier around uplime's rabbit hole
05:15:16 <geist> in C++ that's 'relaxed' vs 'acquire' or 'release' or 'seq_cst'. see https://en.cppreference.com/w/cpp/atomic/memory_order
05:15:18 <bslsk05> ​en.cppreference.com: std::memory_order - cppreference.com
05:15:33 <geist> those directly map to arm64 barriers, or more specifically arm designed their modern arm64 barriers around that model
05:16:06 * kingoffrance puts up "occupied" sign
05:16:18 <uplime> occuplimed
05:16:23 <adu> I can't wait for all the bugs!
05:16:38 <geist> see also https://en.cppreference.com/w/cpp/atomic/atomic_thread_fence
05:16:39 <bslsk05> ​en.cppreference.com: std::atomic_thread_fence - cppreference.com
05:16:40 * adu goes shopping for an arm64 laptop
05:16:45 <uplime> that's cool. multi-processing is making a bit more sense now
05:16:46 <geist> which basically emits a memory barrier
05:17:55 <adu> the only time I've really needed multi-threading is in this one idea I had for matrix inversion
05:20:43 <kkd> do kernels avoid flushing the TLB entries if context switch happens amongst threads of the same process or is it still required?
05:20:48 <geist> https://gcc.godbolt.org/z/6MofjP not that this is particularly a good example, but i more wanted to demonstrate the arm dmb
05:32:58 <bcos> kkd: Avoided for most kernels (same virtual address space)
05:48:17 <doug16k> kkd, no TLB flush when same address space
05:49:08 <doug16k> you can just check whether cr3 actually changed and skip it if not
05:49:20 <doug16k> then it will preserve the TLB
05:49:36 <doug16k> everything in the TLB is still correct if you didn't change address spaces
05:50:42 <doug16k> reading cr3 is 1 cycle
05:54:46 <doug16k> kkd, https://github.com/doug65536/dgos/blob/master/kernel/arch/x86_64/cpu/thread_impl.cc#L1575
05:54:48 <bslsk05> ​github.com: dgos/thread_impl.cc at master · doug65536/dgos · GitHub
05:59:49 <kkd> i see
06:07:01 <doug16k> same with the segment registers. skipping loading them is very worthwhile if they have not changed
06:07:29 <doug16k> in x86_64 kernel, you can just set them all to user data privilege level 3, forever
06:08:03 <doug16k> not including cs and ss
06:08:33 <doug16k> the only reason I even have code for that is to prevent leaking one processes segment changes into another
06:09:06 <doug16k> only berserk or malicious program would change them, there's no point
06:09:30 <doug16k> if you load fs and wreck youf fsbase, I keep it wrecked
06:09:58 <doug16k> (for that thread)
06:13:30 <doug16k> it would be pretty weird for fsbase to spontaneously come back on next context switch
06:13:38 <johnjay> doug16k: where is your OS on github again?
06:13:46 <johnjay> or am i confusing you with someone else
06:13:55 <doug16k> linked a few minutes ago
06:14:01 <doug16k> oh just got here
06:14:06 <doug16k> https://github.com/doug65536/dgos/blob/master/kernel/arch/x86_64/cpu/thread_impl.cc#L1575
06:15:07 <johnjay> ah ok thanks
06:15:51 <johnjay> when you have a lot of repos it gets confusing
06:16:31 <johnjay> also maybe it's just me but github isn't showing it on the listing for some reason
06:16:49 <johnjay> ah ok it is me. first entry and i scrolled past it
08:10:51 <doug16k> how should poweroff work?
08:12:35 <doug16k> send a signal to the init process?
08:13:07 <Mutabah> seems sensible
08:13:20 <Mutabah> then it can tell the session masters that a shutdown is starting
08:13:27 <Mutabah> or request clarification from the user
08:13:36 <doug16k> yes
08:13:51 <doug16k> the orderly shutting down part is where I was lost
08:14:20 <Mutabah> 1. cleanly terminate all processes (deepest firsT)
08:14:38 <Mutabah> 2. once all of init's children are cleaned up, it asks the kernel to start an ACPI poweroff
08:21:36 <doug16k> yeah, makes sense
08:21:45 <Piraty> send sigint to all process, wait some grace time, go down
08:22:24 <Piraty> https://github.com/void-linux/void-runit/blob/master/3
08:22:24 <bslsk05> ​github.com: void-runit/3 at master · void-linux/void-runit · GitHub
08:23:38 <doug16k> ah, just SIGTERM then one(!) second wait then SIGKILL all?
08:23:45 <doug16k> what's the rush? :D
08:24:09 <doug16k> thanks though, nice to know what signals things might be expecting
08:24:24 <Piraty> did you ever 5min wait for systemd to wait on some nonterminating process
08:24:38 <doug16k> yes
08:24:42 <doug16k> that is too much
08:24:42 <Piraty> did you like it
08:24:46 <Piraty> :)
08:25:36 <Piraty> on my system even firefox is usually capable of exiting within that 1s (not all the time, though. but that's expected)
08:25:58 <Piraty> everything else doesn't need more time to go down, and if it does, i don't care
08:36:18 <doug16k> and if it all goes down in under a second, it wastes the rest of the second
08:38:30 <doug16k> I didn't realize that poweroff was a 1 second timeout kill -9 of the whole machine
08:39:53 <doug16k> my instinct would be to formally "join" each process until you know they are all gone, then init exits or shuts down or whatever
08:40:04 <doug16k> after the signal sends
08:40:26 <doug16k> "wait" I should say
08:41:54 <doug16k> the thread sending sigkill will block until it is finished killing?
08:43:47 <doug16k> it could be uninterruptible
08:44:05 <doug16k> the victim could be
08:50:48 <Piraty> you don't want to wait for all childs, some may respawn or not finish or whatever
08:51:47 <Garb0> Piraty, sounds like something a third world father might say.
08:52:01 <Piraty> indeed
08:56:12 <Piraty> doug16k: what do you mean regarding poweroff?
08:56:50 <Piraty> you can't relaibly wait for all childs of init or the supervisor without having a timeout marching on regardless of child state
09:25:19 <Piraty> doug16k: for the first time i see that git keeps an empty file (INSTALL)
09:37:53 <konfujen> izabera:
09:48:54 <doug16k> Piraty, I mean, what if that thread is in the middle of a syscall in the kernel. don't I have to prevent kill from returning until the victim process reaches a point where it can receive signals, and make let kill return only then?
09:49:29 <doug16k> s/make let/let/
09:50:50 <doug16k> "kill" as in `int kill(int pid, int sig)`
09:51:21 <doug16k> or is it just fire and forget?
09:53:55 <Piraty> do syscalls take longer than 1s?
09:55:33 <Piraty> i'm not arguing void linux' way to do it is the most robust, it just seems to not bother anyone that much to propose to increate grace time to >1s :p
10:40:17 <Hydroque> I identity mapped the first 4mb of ram. This holds my kernel in full, as its not higher half. My crt*.o setup faults and I have no idea why, so qemu goes into a reset loop. If I hang before I `call _init`, `info mem` tells me that 0 - 4mb is mapped. Any common reason that crt explodes?
10:45:22 * opios meows
11:04:00 <zid> stack pointer, pages not writeable
11:04:06 <zid> you might want to tell qemu to print interrupt info
11:04:12 <zid> and not reboot on triplefault
11:04:32 <zid> it will show you the #GP you're presumably getting
11:07:06 <Hydroque> hmm my stack is at 00104040
11:07:09 <Hydroque> h
11:10:08 <Hydroque> seems like the irq is incrementing by 1 each reset
11:10:09 <Hydroque> IRQ statistics for isa-i8259: 0: 495 4: 238IRQ statistics for ioapic: 0: 495 4: 238
11:18:48 <Hydroque> aha EIP seems to be > 4mb aligned by 0x1000. Probably a paging issue.
12:47:37 <ybyourmom> you'll get there eventually
12:47:41 <ybyourmom> i belive in u
12:56:21 <Hydroque> I did
12:57:34 <Hydroque> I did `info tlb` and found that I had a weird base value of 1:000000h due to iterating 0x1000 (4096) times instead of 0x400 (1024) times
12:57:51 <Hydroque> I was wondering why EIP was reaching said 1:000000h
12:58:22 <Hydroque> thats it for me today
13:41:47 <G3nka1> Has anyone tried trace-cmd before? I am looking to trace function call trace using ftrace but I don't see the function names in the report. I did "trace-cmd record -p function_graph --max-graph-depth 1 -e syscalls -F ./hello" to record and did "trace-cmd report" to show the trace
13:41:53 <G3nka1> It only prints in this format "<...>-62227 [001] 79639.289626: sys_enter_execve: filename: 0x7fff75650850, argv: 0x7fff7564eef0, envp: 0x7fff7564ef00"
13:58:25 <G3nka1> I mean none of the function_graph plugin trace is being reported
15:04:13 <opios> to know how many pages my kernel is using i first round up the kernel_end and then (kernel_end - kernel_start)/4096 = 11
15:04:21 <opios> is that right? am i doing the math right?
15:07:56 <theseb> what is typical behavior when assembly code tries to pop a value off an empty stack?
15:09:20 <opios> BOOM!
15:11:55 <Mutabah> Well, what's an empty stack to the CPU?
15:12:03 <Mutabah> the stack pointer is just an address
15:14:50 <opios> Mutabah: have you seen my question?
15:15:42 <Mutabah> sounds correct, no idea if the values are right
15:19:18 <opios> 4096 is the page size and of course 11 depends on how big the kernel is
15:19:20 <opios> thanks :)
15:20:18 <zid> there's no such thing as an empty stack, there's not even really such a thing as a stack :P
15:20:20 <zid> it's all smoke and mirrors
15:24:05 <kingoffrance> ^^^
15:24:37 <kingoffrance> theres storage in ram, storage in rom, storage on storage, storage in registers, ...
15:25:24 <kingoffrance> a series of...what for it...cubes
15:25:30 <kingoffrance> s/what/wait/ dammit
15:29:08 <theseb> Mutabah: wait...no nothing!?
15:29:09 * Mutabah is away (Sleep)
15:29:33 <theseb> zid: i agree...i'm simulating a cpu....so just checking what behavior i should simulate
15:30:05 <theseb> zid: if a cpu doesn't do *anything* to flag...then users may miss bugs in their code no?
15:30:38 <theseb> zid: my guess is you'll say...well if they're programming in assembly then they can't expect training wheels?
15:32:31 <zid> incredibly poor guess
15:32:42 <zid> I was going to say your sentences look really bizzare with no spaces after the puncutation
15:40:20 <theseb> zid: I was trying to think if you could make a cpu blow up by overshooting the stack....Even if the base of the stack is at the top of the memory space (e.g. 0xffffffff)...if you "overshoot" it...that just means you'll wrap around and read a value at something like 0x00000003 right?
15:40:37 <theseb> zid: so no danger of undefined behavior?
15:44:32 <isaacwoods> theseb: normal way is to use a guard page
15:44:50 <isaacwoods> you keep the page above the stack unmapped so it page faults if you try and go above it
15:45:04 <zid> below
15:45:09 <isaacwoods> you can use another one at the other end to detect if you overflow the stack
15:47:53 <theseb> isaacwoods: thanks..i'm simulating a simple embedded cpu....is it common for those to just wrap around like i'm suggesting and have no protections? (That would be easy to implement. ;)
15:50:29 <isaacwoods> theseb: I would personally want it to do something other than wrapping if I went above the top
15:50:50 <isaacwoods> but that's two different issues (overflowing an address) and anything to do with the stack
15:52:27 <theseb> isaacwoods: what is something else simpler that embedded cpus do if they don't have paging?
15:53:25 <opios> in virtual memroy we have accessed and dirty bits for when a page is read or write, how can i know which byte of that page was read or write?
16:08:58 <immibis> opios: i think you can't
16:19:51 <immibis> you could leave it read-only or not-present and emulate instructions which access it, perhaps. with a horrible speed penalty
16:24:37 <opios> yep
16:28:40 * geist yawns
16:46:50 <geist> http://www.righto.com/2020/08/reverse-engineering-adder-inside-intel.html oh this is interesting, talks about a Manchester carry chain
16:46:52 <bslsk05> ​www.righto.com: Reverse-engineering the adder inside the Intel 8086
16:47:00 <geist> never read about that before, but totally makes sense
16:47:16 <geist> or at least i'd always read that there was a fast carry mechanism but never looked into how it works
16:48:18 <geist> that plus appaently a carry skip mechanism every 4 bits
16:56:39 <gorgonical> Off-topic question about backgrounds: how many of you have computer/electrical engineering backgrounds vs "plain old" CS backgrounds? It took me a long time to become productive and I think a lot of that was lack of hardware-level instruction in my CS curriculum
16:56:55 <gorgonical> Whether schooling, self-instruction, etc
17:00:44 <kingoffrance> i think historically that was supposed to be cs but maybe its been watered down so cs is now "software engineering" ?
17:01:02 <kingoffrance> djikstra something something astronomy something telescopes something
17:02:06 <kingoffrance> saw a great fortune the other day: digital computers are made of analog components
17:05:37 <kingoffrance> never forget, agile came from manufacturing world
17:05:50 <kingoffrance> i think its all likely watered down whatever you take
17:19:30 <kingoffrance> plus theres a class of ppl who want to move to verified languages, etc. for everything. not saying thats good or bad, just even some "low level" stuff they try to avoid giving ppl sw access to hw as much as possible
17:19:58 <kingoffrance> youll poke your eye out
17:20:49 <mra90> what is the point of INIT_WORK() in kernel
17:21:05 <mra90> it seems to schedule task in some unknown period
17:21:12 <mra90> what is the point of that?
17:22:53 <siberianascii> doug16k:
17:25:10 <kingoffrance> theres also ppl who think you are just being masochastic, you couldnt possibly be wanting to learn anything anyways, you just are a glutton for punishment if you peer behind the curtain of <insert lang> <insert os> etc. --- so i never expect "encouragement" i suppose, http://herpolhode.com/rob/utah2000.pdf "Systems Software Research isIrrelevant" thats the timeline i came from
17:39:27 <kingoffrance> (i disagree on his breadth vs depth though; you can do depth, then try to spread it)
17:40:00 <kingoffrance> you need something to spread first
17:41:05 <geist> mra90: which kernel?
17:41:38 <immibis> gorgonical: CS is not designed to be SE. CS is science/mathematics, it's not how to build things
17:42:31 <gorgonical> immibis my limited experience has been that all the people that know osdev per se seem to come from hardware backgrounds, so CE/EE. that's why I asked
17:42:49 <gorgonical> i was taught exactly one class on hardware components in my CS curriculum and that was just asm programming
17:43:17 <immibis> mra90: linux? https://lwn.net/Articles/11360/ <- INIT_WORK fills in a structure, queue_work queues the work
17:43:18 <bslsk05> ​lwn.net: Details of the workqueue interface [LWN.net]
17:43:47 <immibis> and "an indefinite time in the future" means, in practical terms, "as soon as possible unless the system is busy with something more important"
17:50:30 <geist> i'm not gonna say that it's a requirement at all, but I also come from a CE background
17:51:02 <mra90> geist, linux
17:51:05 <geist> but i thinki t's less of whether or not you need a CE/EE degree to do low level kernel stuff (you dont) but more that folks that are interested in low level programming tend to be more inclined to study CE/EE
17:51:15 <gorgonical> hmm
17:51:15 <kingoffrance> i guess i am pikeish "But art is not science, and that’s part of the point. Systemsresearch cannot be just science; there must be engineering,design, and art." holistic
17:51:22 <mra90> geist, linux 5.8
17:51:30 <mra90> immibis, right, thanks
17:51:56 <gorgonical> I always thought that maybe ce/ee gave you some kind of advantage. improved familiarity with hardware and its limitations and the modi operandi that people like me have to puzzle through
17:53:41 <geist> nah
17:54:37 <kingoffrance> to me os is the intersection of interacting directly with hw, plus your kernel architecture, plus your systemwide sw (base system/utils), plus whatever math and art (technique, style, subjective feel) perhaps supposedly ties all that together maybe
17:55:10 <siberianascii> to me os is too big of a topic to describe in your two lines above
17:55:49 <siberianascii> it has far more definitions depends on the point of view
17:58:56 <Bitweasil> mra90, I believe that macro just sets up the workqueue stuff, and you later toss it in the actual queue.
17:59:07 <Bitweasil> It's the boilerplate macro, you set up the rest as you want.
17:59:45 <geist> my guess is you can use it during contexts like early bootup or irq time when you shouldn't be running large chunks of code
17:59:55 <geist> so it tosses it on a work queue that's run later, but probably pretty quickly
17:59:56 <Bitweasil> CS is, in most places, a math degree and involves people who don't like getting their hands dirty with actual hardware.
18:00:00 <geist> but in some sort of thread context
18:00:02 <Bitweasil> CprE is more hardware interaction.
18:00:24 <gorgonical> Bitweasil I would say that was my degree, with some SE peppered in
18:01:01 <Bitweasil> geist, correct, that's part of the workqueue system, which can either be "Run this as soon as you have a chance" or with various delays. It lets the interrupt handlers be nice and quick - hand off the hard work to a kernel thread.
18:01:17 <Bitweasil> The workqueue system is actually pretty slick.
18:07:04 <kingoffrance> https://queue.acm.org/detail.cfm?id=2349257 that too, didnt seem to get a warm welcome, just i think speaks to lack of "systems" although ppl can reasonably differ on how much "integration" is good of course
18:07:07 <bslsk05> ​queue.acm.org: A Generation Lost in the Bazaar - ACM Queue
18:17:52 <immibis> not just interrupt handlers, but anything that's asynchronous, presumably
18:20:23 <immibis> if you don't want to block the calling thread
18:20:49 <rain1> did you all finish your OS's yet?
18:24:58 <geist> hah, no one finishes their os, ever
18:29:16 <adu> I never started
18:29:24 <geist> or that!
18:29:57 <adu> although I have written a lot of bootloadery things
18:31:23 <geist> well, no better time than now
18:33:11 <doug16k> threaded IRQ makes every IRQ then causes three context saves and restores. the save for the irq, restore context into worker, run irq handler, wake waiting thread, block on work queue, save context, restore the one that got completion
18:34:30 <doug16k> two context switches I actually
18:36:56 <kingoffrance> os finishes you
18:37:29 <doug16k> I have a kernel worker per cpu, and I used to do mostly threaded irqs, but realized that often the irq wakes one thread and that's it, why not wake it and just return right into awakened thread from irq?
18:38:54 <doug16k> threaded is not worse if the waiting thread is not the same cpu as where it routed the IRQ though
18:42:46 <doug16k> the only compelling reason I see for threading irqs is if you wanted to do something like allocate memory in the irq handler
18:44:01 <doug16k> aren't the extra context switches expensive when you use threaded irq?
18:48:00 <doug16k> in my kernel, the fpu made it worse. each irq it would preempt the user thread, save fpu, restore nofpu workq context, clear and block fpu, run work item, block on empty queue, save workq context, choose the thread that just got completion, restore fpu context, unblock fpu, continue
18:48:16 <doug16k> pretty rough
18:52:13 <doug16k> to do threaded irq with reasonable efficiency you'd probably want to do lazy fpu, so it can avoid touching the fpu altogether while running kernel worker, leaving whatever was in the fpu alone
18:52:20 <adu> geist: I'm not sure I'll ever start an OS
18:52:52 <adu> I might write my own firmware
18:54:25 <adu> my goal is to figure out how to write a microcode update to turn intel chips into arm64,
18:55:07 <doug16k> adu, have you considered building a spacecraft instead? might be easier
18:56:04 <doug16k> microcode authenticity verification hasn't been broken yet right?
18:57:03 <adu> I think it has on AMD like whatever version was available in 1995 has been broken
18:58:22 <adu> but Intel's microcode is still a black box so far as I know
18:58:46 <doug16k> I think there were a couple of small leaks
18:59:01 <doug16k> some fool uploaded secret internal documents to a public place
18:59:20 <geist> oh yeah iirc someone very recently managed to crack the encryption on modern ones
18:59:21 <geist> i think
18:59:23 <adu> those were architecture docs
18:59:48 <doug16k> some microcode source
19:00:07 <geist> ah well i wouldn't touch those then
19:01:05 <doug16k> the bit I saw was some power on initialization microcode, IIRC
19:02:17 <doug16k> if I did get my hands on x86 microcode, the 1st place I would look is the cpuid instruction, to see why the cycle count is so ridiculous
19:02:45 <immibis> adu: do you want to know how possible that goal is?
19:02:47 <doug16k> sure being serializing is bad, but that doesn't account for it. must be something to do with cpuid being used to load microcode? ut how
19:03:10 <immibis> unless by "turn it into an AMD" you just want to change the CPUID vendor name. that could be doable if the encryption is cracked.
19:03:15 <adu> immibis: not really, I just want to die trying to achieve it
19:03:41 <immibis> you might have better luck making an AMD-compatible CPU from scratch. including bottles of toxic chemicals and particle accelerators in your garage
19:24:03 <adu> doug16k: are you talking about this? https://github.com/tianocore/edk2-platforms/tree/master/Silicon/Intel/KabylakeSiliconPkg
19:24:04 <bslsk05> ​github.com: edk2-platforms/Silicon/Intel/KabylakeSiliconPkg at master · tianocore/edk2-platforms · GitHub
19:31:41 <doug16k> no
19:32:05 <doug16k> it was top secret, not bsd
19:33:02 <doug16k> someone here linked it
19:42:13 <geist> yah the encrypted packages i think are basically freely downloadable
19:42:27 <geist> for doing microcode updates. it's actually kinda easy
21:43:52 <Bitweasil> I'm pretty sure Linux ships the microcode update packages - I know it can patch CPUs at runtime.
21:43:57 <Bitweasil> Or Windows does.
21:44:03 <Bitweasil> One of the two will update your microcode if it needs it.
21:44:38 <Bitweasil> https://wiki.archlinux.org/index.php/microcode
21:44:38 <bslsk05> ​wiki.archlinux.org: Microcode - ArchWiki
21:48:03 <heat_> they probably both do
21:48:28 <geist> yep, key though is it doesn't 'stick'
21:48:40 <geist> you dont actually flash the cpu, it has to be reloaded on every boot
21:48:55 <geist> so the reason your OS would update microcode is if your BIOS/firmware is too old to have updated it already
21:49:05 <geist> the cpu itself boots up with whatever microcode it was rommed with
21:51:19 <heat_> is there any particular reason as to why they don't flash the CPU?
21:51:49 <geist> they dont put flash on the cpu is my understanding
21:52:44 <geist> and probably far more secure to have it in rom
21:53:19 <geist> and then have an ability to run time patch it in the sram cells as it was loaded into the cpu
21:54:16 <geist> i'm assuming that a sizable chunk of the run time microcode is actually sitting in some sort of distributed SRAM. a bit here or there, a table of microistructions, etc
21:54:36 <geist> much like how you'd load an FPGA. the sram cells at that point can run at full speed since they're just a pair of transistors probably
21:55:07 <geist> so if it's hard rom it's hard rom, but if it is patchable it has to one way or another be read out into the sram, either from flash or from some sort of storage rom
21:55:24 <geist> so i guess the lack of flash is some sort of price/safety/security thing
21:55:57 <geist> but that's just my guess, based on what i've seen. i have no idea what the inner mechanism is
22:10:24 <doug16k> flash memory is too flaky
22:10:55 <doug16k> what, have a complex multilayer ecc thing too?
22:19:29 <doug16k> it has flash memory, it's the firmware
22:19:41 <doug16k> why recreate a part that is already there
22:23:05 <Bitweasil> I imagine doing flash memory on a CPU process tech is probably also a pain.
22:23:14 <doug16k> yes
22:23:32 <Bitweasil> So easier to just not, and, as doug16k notes, you've already got boot code in flash, what's a bit of microcode patch in there too?
22:24:58 <heat_> it just came to me, why exactly are NICs faster at doing a bunch of things if our CPUs are probably much much faster than the NIC?
22:25:05 <doug16k> imagine having their transistor budget? probably a bit like my kernel vs my 64GB of ram. totally infinite ram as far as my kernel is concerned, and there would be infinite transistor budget if I were writing a cpu :D
22:25:44 <Bitweasil> heat_, stuff like hardware offloading? Because fixed function hardware is almost always going to be faster than general purpose hardware.
22:26:15 <Bitweasil> A set of transistors that does CRCs with a fixed algorithm will be quicker than doing things on a CPU where you have to read the bytes.
22:26:17 <doug16k> because you don't want to have to touch every single packet and cache miss with the cpu
22:26:20 <heat_> Bitweasil: really? even with all the caching and stuff
22:26:32 <Bitweasil> You can literally just pass the data along through your CRC engine as you're reading it off the line and check it at the end.
22:26:49 <Bitweasil> So by the time you get to the checksum, you just check your fixed function hardware, see if it matches, drop if not.
22:27:03 <Bitweasil> Fixed function hardware is /very fast/.
22:27:17 <Bitweasil> Just, generally does only one thing.
22:27:27 <heat_> doug16k: but that's the old way to do it, linux for example checksums while it copies the packet from user-space
22:27:35 <Bitweasil> You can't change out the CRC algorithm in your NIC, but as it's part of the ethernet spec, well, not going to change.
22:28:02 <heat_> so the only cache misses you get are from protocol and net headers which are bound to be touched anyway
22:29:01 <Bitweasil> The NIC hardware checksums the packet before it even gets into the system's memory heirarchy.
22:29:01 <geist> but that being said i think the really high end nics do tend to have at least some cpus on board
22:29:05 <geist> just dedicated stuff
22:29:15 <heat_> and for example I imagine doing segmentation offloading is *not* simple but they do it faster
22:29:27 <heat_> (than something like a 4GHz modern x86 CPU)
22:29:56 <Bitweasil> Sure. The hardware is built to do it. Also, remember, you're freeing the main CPU cycles to do something else.
22:30:09 <doug16k> it's not a matter of being faster. it is an offload. if you offload it and your offload is much slower than the cpu, it's good enough as long as the cpu probably won't offload another thing before you are done
22:30:11 <Bitweasil> So even if it's not actually faster, wall clock time (which it probably is), freeing up the main CPU to not do network crap is worth a lot.
22:31:00 <doug16k> shortens the sequential portion / Amdahl's law
22:31:13 <doug16k> now shorter sequential bit and partially concurrent bit
22:31:31 <heat_> hmmm
22:31:58 <heat_> so you say that by offloading stuff to the NIC i'm able to queue more work and improve throughput that way?
22:32:08 <Bitweasil> Maybe? It depends on what you're trying to do.
22:32:20 <Bitweasil> But if the NIC is calculating packet CRCs and the main CPU doesn't have to, then the main CPU can go do other stuff.
22:32:50 <Bitweasil> If it's a lightly loaded box, this probably doesn't matter. But if you're a bulk compute box in a datacenter, CPU bound, then it's absolutely a win to have coprocessors.
22:33:02 <Bitweasil> (and the NIC can be viewed as a special case coprocessor for network packets)
22:33:31 <Bitweasil> I believe some of them can even do stuff like "Put the packet data in the correct place in memory" for streams going to applications, and that's before you get to the userspace NIC stuff.
22:33:32 <geist> also for stuff like pppoe or vlan or whatnot, if you can offload that stuff it's nice
22:33:38 <Bitweasil> Where it literally DMAs into the process memory space.
22:33:44 <geist> also dont forget tcp/udp segmentation offload
22:33:50 <geist> which is fairly complicated
22:34:17 <Bitweasil> Then there's the RDMA stuff... :/
22:34:22 <Bitweasil> And RCMA, when DMA is too slow.
22:34:27 <geist> i think that probably requires at least some amount of embedded cpu, but you just dont see it because it's built in
22:34:30 <heat_> Bitweasil: the linux networking stack doesn't zero-copy to user memory
22:34:41 <Bitweasil> No, but some high end NICs support that.
22:34:44 <Bitweasil> I think.
22:34:59 <doug16k> non-crap nics all support scatter/gather
22:35:12 <gorgonical> heat_ there are user-level networking stacks that do support zero-copy
22:35:27 <Bitweasil> Yeah, https://en.wikipedia.org/wiki/Data_Plane_Development_Kit
22:35:28 <bslsk05> ​en.wikipedia.org: Data Plane Development Kit - Wikipedia
22:35:30 <heat_> yeah I imagine, but I was talking about the kernel's stack
22:35:32 <gorgonical> snabb also
22:35:40 <Bitweasil> "It provides a set of data plane libraries and network interface controller polling-mode drivers for offloading TCP packet processing from the operating system kernel to processes running in user space. This offloading achieves higher computing efficiency and higher packet throughput than is possible using the interrupt-driven processing provided in the kernel."
22:35:44 <heat_> which I imagine is wayy more used than user-space stacks
22:35:47 <gorgonical> DPDK is the bigboy stack
22:35:59 <Bitweasil> Sure, but point is, various options exist.
22:36:12 <Bitweasil> Do they matter for me, at home, watching a cat jump into a box on YouTube on a little laptop? No.
22:36:18 <Bitweasil> Do they matter for datacenter folks? Absolutely.
22:36:39 <heat_> >at home, watching a cat jump into a box on YouTube on a little laptop
22:36:45 <heat_> I'm in this message and I don't like it :(
22:37:00 <Bitweasil> It's a lie, I don't watch videos on computers much.
22:37:04 <Bitweasil> Except the TV computer, in the evenings.
22:37:08 <Bitweasil> And I think YouTube is horrid.
22:37:12 <Bitweasil> but it's a common enough use case.
22:41:46 <Bitweasil> Anyway, enterprise throughput related stuff is quite complex.
22:44:13 <heat_> is it too naive to assume that big web servers use the classic BSD sockets API stuff?
22:45:07 <Bitweasil> Yes. If it's a performance critical system at a major web company, they're probably using something custom.
22:45:24 <heat_> in the classic "int sockfd = socket(...); bind(INADDR_ANY); listen;" with maybe some kind of complex thread pool with accept and some setsockopts
22:45:24 <Bitweasil> Wouldn't surprise me if Google/Amazon/etc were doing userspace networking for some of the critical stuff.
22:45:57 <Bitweasil> Early on, I think Google did some bizarre async stuff with callbacks for their web servers, because it was far faster than threading.
22:46:23 <Bitweasil> You can also assume there are several layers between what accepts the external socket connection and what actually answers the request.
22:46:33 <heat_> hmmm
22:46:47 <Bitweasil> So if you open a HTTP connection to google.com:80, that's not the HTTP server, that's a request router.
22:47:00 <Bitweasil> Some sort of frontend that routes things.
22:47:14 <heat_> I've been reading quite a lot of cloudflare blog posts because they usually have quite a few interesting posts and they don't seem to have a very complex setup
22:47:19 <heat_> and they're relatively big
22:47:35 <Bitweasil> Cloudflare certainly has some interesting posts, but they're also very, very single purpose.
22:47:41 <Bitweasil> So they tend to optimize for that.
22:48:00 <Bitweasil> Yes, they do some image resizing and such, but in general, they're doing one thing, as fast as possible, and are quite good at it.
22:48:16 <Bitweasil> But the inside of any modern web firm is horrendously complex.
22:56:07 <geist> yay splitsville!
22:56:08 * Bitweasil wanders out.
22:56:11 <Bitweasil> Later!
22:56:14 <geist> hellow this side of the split!
22:56:16 <Bitweasil> I have join/part turned off. ;)
22:56:20 <Bitweasil> So I don't notice.
22:56:21 <geist> welcome to our half
22:56:44 <geist> looks like only one server fell off, since we only lost 15 or so people
22:56:45 <Bitweasil> Our side is the best side.
22:56:55 <Bitweasil> We've got stars upon ours!
23:00:57 <geist> oh the Others are back