klange changed the topic of #osdev to: Operating System Development || Don't ask to ask---just ask! || For 3+ LoC, use a pastebin (for example https://gist.github.com/) || Stats + Old logs: http://osdev-logs.qzx.com New Logs: https://libera.irclog.whitequark.org/osdev || Visit https://wiki.osdev.org and https://forum.osdev.org || Books: https://wiki.osdev.org/Books
gog has quit [Ping timeout: 248 seconds]
gog has joined #osdev
Vercas6 has quit [Remote host closed the connection]
Vercas6 has joined #osdev
nyah has quit [Ping timeout: 248 seconds]
[itchyjunk] has quit [Ping timeout: 255 seconds]
<heat> how many TLB entries do you need to flush in order for a full TLB flush to be worth it?
<gog> i guess it depends on the size of the working set
<gog> compared to the number of TLB entries
smach has joined #osdev
scoobydoo has quit [Read error: Connection timed out]
scoobydoo has joined #osdev
<heat> for context, I have this optimization sitting on my local branch where, when COWing in fork(), instead of doing a TLB shootdown when COW-ing a memory region I do a TLB shootdown of every address in the end
<heat> I guess I could try another strategy and buffer TLB shootdowns, and then flush them all
<heat> that's also interesting... I don't know if it has been done though
<heat> right now my strategy for TLB shootdowns is to go through the memory range in the page tables, collect A bits and TLB shootdown ranges of pages
<zid> you're shooting down because the pages are becoming -w to do the COW?
<heat> yes
<heat> I don't think I can avoid that
<zid> I'd just invplg as I went marking the -ws tbh
<heat> but I can't just invlpg, I need to invlpg to everyone
<zid> everyone?
<heat> every other CPU executing my address space
<zid> kinky bastard
<heat> no u
<zid> so I guess you INNER JOIN on your list of threads?
<heat> fuck no that's slow
<zid> you're going to have to tell them at some point
<heat> I maintain a cpu set of cpus executing the address space
<zid> also why would it be slow?
<heat> when you ctx switch to set it, when you switch out you unset it
<heat> i'd need to go through every thread
<heat> that's not very gangsta
<zid> process you're forking knows its threads, you set a bitmask for each cpu that thread is on, then for loop over your page tables sending an ipi to each set bit for each page, or you ipi to tell them all to dump the entire tlb
<zid> s/that thread/a thread
<heat> yes but that's already pre-computed
<zid> okay then you already did the slow thing, grats
<heat> also address spaces aren't really a process thing so...
<zid> so I guess all you care about now is the ratio
<zid> between "how many invplg" and "kill the entire tlb"
<heat> korrect
<zid> Let's start with 7
<zid> and adjust it until it performs better
<heat> not really "how many invlpg" but "how many shootdowns"
<zid> a shootdown does an invplg, the count is identical
<heat> a shootdown is 20x more expensive
<zid> ??
<heat> IPI
<zid> You do know I am literally talking about invplg via ipi right
<zid> not an invplg that won't do anything because it's on the wrong cpu
<heat> yes
<zid> the amount of *remote* invplgs is the same as the number of ipis, so I can use "the number of invplgs" just fine
<zid> to also mean the number of ipis
<heat> ok sure
sikkiladho has quit [Quit: Connection closed for inactivity]
<zid> So yes, start with 7, I assume that's easy to calculate because you know the memory map in terms of ranges somewhere?
<zid> ala /proc/pid/map or whatever
<zid> and you'll need some crap for shm I guess
<zid> It's sounding more and more like you'll want to just do it blindly tbh
<zid> given how annoying it will be to actually find out the answer of *what* needs flushing
heat_ has joined #osdev
<heat_> my router just shootdowns my connection every so often
<heat_> its gr8
<heat_> <heat> right now it's not easy to calculate
<heat_> <heat> I'm iterating through every region and mprotecting it COW
<heat_> <heat> and an mprotect of a range can invalidate N pages as well as it can invalidate 0
<zid> [02:28] <zid> It's sounding more and more like you'll want to just do it blindly tbh
<zid> [02:28] <zid> given how annoying it will be to actually find out the answer of *what* needs flushing
heat has quit [Ping timeout: 256 seconds]
<heat_> yes, it's hard
<zid> given shm + walking multiple ranges
<heat_> a strategy would be to buffer tlb invalidations in a list and then flush that shit in the end
<zid> Or you could just drop the tlb and not waste 10kB of icache with this code ;)
<heat_> booo
<heat_> let me overengineer
<zid> I can't find the x86 version of [02:28] <zid> It's sounding more and more like you'll want to just do it blindly tbh
<zid> [02:28] <zid> given how annoying it will be to actually find out the answer of *what* needs flushing
<zid> fuck
heat_ is now known as heat
<heat> fuck
<zid> of flush_tlb_mm
<zid> I know where alpha, arc, arm, csky, etc is
<zid> oh I found it, it's a macro for _range
<bslsk05> ​elixir.bootlin.com: tlb.c - arch/x86/mm/tlb.c - Linux source code (v5.19.2) - Bootlin
gog has quit [Ping timeout: 268 seconds]
<zid> I got a really extra hot bit of hot sauce, in a big glob
* zid dies
<sauce> :o
<zid> sauce: pls stop
<heat> you're so fucking hot
<heat> holy shit
<heat> you're asking for it
<zid> tlb_single_page_flush_ceiling exists too
<heat> its "33"
<zid> but I can't actually find, where it lives
<zid> extern unsigned long tlb_single_page_flush_ceiling;
<zid> is the closest I can find
<heat> tlb.c
<zid> tlb.c where
<zid> arch/x86/mm/tlb.c uses it 5 times
<zid> maybe config.h sets it
<zid> from kconfig vars
<bslsk05> ​elixir.bootlin.com: tlb.c - arch/x86/mm/tlb.c - Linux source code (v5.19.2) - Bootlin
<zid> so my guess of 7 wasn't far off
xenos1984 has quit [Read error: Connection reset by peer]
gog has joined #osdev
xenos1984 has joined #osdev
heat has quit [Ping timeout: 256 seconds]
fluix has quit [Remote host closed the connection]
fluix has joined #osdev
<geist> zid: oh hitting the sauce again?
dude12312414 has joined #osdev
dude12312414 has quit [Remote host closed the connection]
<zid> yea sadly I only got a little bit inebriated
<sbalmos> I don't think I've heard of someone getting inebriated on hot sauce. that's certainly a different buzz.
<zid> I genuinely got high off a curry once
<sbalmos> oh yeah, reaper is don't-f***-around level
<geist> aww dont fear the reaper
<zid> hahah I google imaged it, and one of the results is "picture of man having eaten one"
<geist> wouldn't hot by UK cuisine standards be like a chili pepper on the same table as some peas?
<zid> we have the largest indian immigrant population in the world though?
<zid> It'd be like making fun of texas for not being able to handle chili
<zid> red dwarf is almost entirely about trying to find a good hot curry
<sbalmos> gimme some good hot harissa sauce though
<zid> that seems nice
<geist> well,that's true. one time on a business trip to Korea the locals all tried to make us eat hot stuff at lunch to try to show off their cuisine. now, i can tell you korea has some spicy stuff
<zid> yea it really dos
<geist> but... living in bay area at the time there's also fairly spicy stuff around so it wans't successful
<bslsk05> ​digitalcontent.api.tesco.com <no title>
<zid> That's my favourite pot noodle
<zid> and I think it's pretty fuckin hot
<zid> they also sell it in "double hot"
<geist> but i remember the koreans laughing that the week before they took some italians out for lunch the week before and they were totally not up to it
<sbalmos> oh yeah, a bowl of Maruchan spicy chicken
<geist> which i guess makes sense, you dont think of italian cuisine as being particularly hot
<zid> The spiciest thing an italian is like to eat is black pepper
<zid> L2Iep+jW2VxWHS8qlc0gqdYIMETxq2oQ8laxs+36Vz7Rovpq4AfIqVKlVlCpUqVQgjXmjpQ5F19N7Nodx14Hge8e/dXpY15p6SuC1wMYEknvHd3gn40uYcCg2VbW3dDHXU5Zj6kkv4BhoOM8BBI+mDpduWuqWJQANdMktLTkWOZ36Dw3ULbIxiZ4vAFTLDkrgQP3SBBHcvKrjpH0qW+9spZCi2IzagtvzkDcoYnd3DiTQO7CQOMoMkOXjeRC6a66gyND+FOW7WmYXBAAMMDoDuMiZ1nhXKWV+i6ga+dIbXfP0TppI9lKBlIzSxAXScqqDMAnUmQKsokWSy9kjRvoz2GB+qRuMEajnrO6pOGt5WkGR9EnkVDSRzhl03TPdP3B2xdLFxwkoJy
<zid> /8QAGgEAAgMBAQAAAAAAAAAAAAAAAgMAAQQFBv/EADARAAICAQMCBQMDAwUAAAAAAAABAhEDEiExBEETIlFhcQWBkTJCUhSh0SOx4fDx/9oADAMBAAIRAxEAPwDcKVKlUII1k/Sjyp3rNx0tWbcKSJcsSYMTAiN1awa8y9MkJu3T+0x74k0Egok655YNpudGsJ6Non7TGn9oeUnatqJv2zIn5hR8aANnqC4B4+ujLp1ZssU6nMFFpQxYBQHAy7yQuu+JmhbSLW4y3lc2p+uT/TQfdXxfKttM/wDUAf4dv7xQjcCjRSh74ZveF1pNbU6hlHd5v2gKosN8P5V9og9q9P8Ah2v5autneWHFhouJauD0SjR4qxHurM3wpAnXvn4ju/rnTuFWWAq
<zid> mPNy/VOhB7j418wmbrGz6E69wbgdO4nTwqgj0R5Mf0C36T79/nHfRZQp5MmnAW/Sf7Rorp0eBUuRUqVKrKFSpUqhCu29j1s2LlxjEKY9IiB768z7evoZk7zXpjb2y1xFl7LaZhoeRGoPtrzbtzDdVcdGQShIPiDBpcuQ48Ayqr9b2lR8TXbBBozMfAq2nqJr7cx5G5a+XcZcUCVIndOk1CC6yx+37BXxHt6ROvh7vdTR2m/Kvq7QY8P69lQsssDdtg8O6SRry0qUzqWmQJiIaf6NVVnFn6oqbh7wJgoPYKqi0ze/JDjQ2Fa3MlHn1MBHvBo8rP/JJsTqrBvnQ3dFH7Kk6+sz7O+tApkeBcuRUqVKrKFSpUqhBV5t8on6XiDzuv9o16Srzb5
<zid> Qz+c3/71/j/ALUEuwUe4F217SxvJFFPT3BMtywpbN+b2DPa0GSQO0f9vChh96+NEvSe6xVWYk/IWQJ1gQwGvqHsoWECVm1mOUKT4ST4xX3q94iCOfIb5q52OjIAQFht+vaImDpyBk8d9N7VE3EYqVJkalTMTroT3b+6g1eai9O1lUlT8B51QEqfg/Ooyj0/0H/QMN/dLV7VB0DP5hh/Q+BIq/pi4AfIqVKlVlCpUqVQh8rzX0+bNib3psfjXpSvMnTZ/wA4un9tviaCXIUe4LNqV0nuG+i/yh2OpGHt5AJw1k5pnNodT379O+hItBEfWijHyl4lWXCQxJ/JbUzwMPHE67vdQsIG9lMxGZSOzlDAqWMBiwK5dfOJ08KjbTusHAbLmEsQswCQ
<zid> BpPcAT3zTez8UbRkctfH7+ccwB31Fu3MxzHeSZ9v9a99Co72Xe1DjpEciJqbgvPFRLDSwB3ERU3B6EHviiKPS3k8adn4fwb7bUSUMeTU/wDD7H7/ANtqJ6YuAHyKlSpVZQqVKlUIfK8y9MPn7mn0m+Nemq8w9Mbny1z0m+NBMOHcHEYBtY3k6xw9R1os6alosgkkC0uhAGiAluHAuAI0ksaDxehuO/u594NE/SfEhlsEL5tlF3ncJ7PvGvdQtBIF72mh1InlrqRoPV8K5J11g79Y5QTA46Eca5u4jXQcuPL1d9cC73er2fcBP3VZROtDXdqInQccswY4Tu7xT2CGoHj7o/Goi353zvBPiAB9x9vdUrC3O0PX374/ChCPSPkyP/D7Pi/2zRV
<zid> Qn5LmnZ9rxf7RospseBT5FSpUqsoVKlSqEPleYuleEuNfeEY9puEDf316dNeYelmMbrWGu872bn+yRS532Dh3KC3se+zgC0SZ3Sv3mibpHsPEIlsNb1yiO0hPubd/vQpYxrZxoDrxNz+erPau1WczlWFEDzo0/eoHqCWkqrux78/Nn2r+NJNkX/1Z9q/jTNzHNO5f4v5q+pjW5D23P5qnn9ibE1NjYj9U3tX8akW9m3lYTaceqfhUJMe3L+O8Pg9TsNtFsw37uFy797Gp5i/KehPJXP5AgIIh33+NGFB3kqulsCCZ+cfeZ5UY06PAqXIqVKlVlCpUqVQh8NeW+lCjr9TvJJ8JP4GvUjbqwLb3QW6SbhvIN/ZCsfeSOdLm0t2MxpvZGdYYpn
<zid> bgDEabhEGO/dHrqfjrVoW5VmJMwMoG7TXUxr8D6rXD9EQD2r4HflA+LVM2p0StqoC4jNIB3Lx8GpDz4+bHeDP0Ae8iDLxBMkkaxu3d+p9nKu7fVbyZPLKQB7N8fdrVyeimulw/5f8Aevp6JMP+b/B/+qr+pxfyJ4E/QpmVQIUzrvgjTLu9pPsHrm4NU0kkNBjlpETp3n2VZ2+iT6DrR/kP81TcP0NuysXEOnEMPxqLqMcuJEeGa7GyeSSPyIwZ+Vf4LRtQh5MtnPYwpRypPWEjKSRGVeYHKi+tUeDPLkVKlSogRUqVKoQ5bcayTbbDMw7jWpbSvZLbt3H2nQVku2bZaTMEn+vcK5n1CapI6HQw1Ntg9jcGWYfV408tgcqmgaVIsYEmuI8rq
<zid> mdNorVw4p9MNNWv9mmK5GFK8KXKbK2IiYTURNTcMhBGp99P4VRmE/0f6mpGKHaA5A++IqlKTWqwZLsGnRF5smTMN9wq+oV6G3/OXmAR6t/xoqr1XSS1Yos4meNZGKlSpVpFCpUqqdsY4qMq7zvPKl5MkccdUgoRc3SK/pFjcx6tdw3+NC1/DjlNWzimHVRv9n415zqeo1ybZ18EPDVIhW9lrE+6nreHjhTwblXatzrLFxe6Q1tnJQRTN22KlHUU2QKKTIiqxFoCuEbXU+0zU7GYfMpFUgwZU8teVKjGD3bodFKSCTZOINtww4GjzD3g6hl3GsxwLnnuok2NtMoYOqnePvHfXY6HqlB6G9jn9X07fmXIX0q5RwQCNQd1dV3DljGLvZFLcvjw
<zid> oSv3cxJJ31b9I7x7KDxPwH30N3r2hrifU82+n0Oj0mPy6vU+X8RyqJnpu5dG7jxpprorzctU3bOiokxbsV8/KhzE1CF+uLr6aUUdS2C0lle2gqDU1wuKU9oGaFLkuTv75qywNrIIrTPaPuNlijGPO5ctiJrkrm0Ht5VFSpFu4BB5f0ay/utimq4Onw3VwwMrx7u/wpxXA476dvvI0AKneO41WdTCm3O7zSeXD3VtdQqUSorVyHfRzGZlyHeNR99XtAXR7EFMs7wf/f30d16PoM3iY9+xxusx6J7dwY6RXflD3AUMYi55wq56TXouuPD4ChnG4jsmDH/uuR1ycpyNvT7QR9dgBPHjTIeDJqA1+Dvpm9itZFc+OJmxMszdHMA7x4CuXuTuNUy
<zid> 4gE99PflIFH4NBNk9QK4vYjLB4SKgJjA26vj3iTqRFWsTvctS33Ly1iNKdW6Kp7d4Cn1u7oNKliKbRYttErlEQDInf4V1avSdd4qHbuAgDvr6b0NFDJNqiWqCDCXN1H2FMop5gfCs2wd7UVo+APyaeiPhXf8ApV1I5XW8oynyiY64mIuBXI1HAH6I5is82ntvEZW+VP8AlT8KPPKb+k3P3fsisy2p5rV0njg3ukZlOSWzIV3pHiZ+dPD6Kfy00ekmI/WfwW/5arr28+qmSdatYofxX4RPEn6v8lwekeJ+uB+5b/lp5Nr4wiQ0j0Le72VXbLsB3E+aNTxot2DsfEYpwts5BqSZIVVByliRJ3yo0JYhuCsVGUIJ0or8DoyqOqcn7Uyhs7XxTG
<zid> FbXcfk7Y/8a+vtzFLozx+5b+OWj7aHk8vqha1eFxhqUVTbLdy9ohj3HL40HYm0biMG1ZRIJ3nxJ19usT6gagnvFV8DIvVtGTv5If8Ab+J/W/wp/LUhOkGI/W/wW/5apKeSr8HH/FfhGbxZ+rLmx0ixGUfKcT9BOZ/ZqRiOkOIzJ8p9b6Cd37NUdjzR4n4mp13B3D1bhGKligYAkFyA2UHiYBMfiKF4cd/pX4RfiT9WFeyNtXywm5/Cn8tb7sNycPaJ3lF+FYXsbYrWWW5icoX6Kh1LsY3gA6geO+Bzrc9htOHtECBkWBy0pmJQTelfgHI5Pkyrym/pNz937IrM9qDRq1LyjYdmxF0qCcozHuAUSaENrbDw6W2F3EdXdBWRAbMrWrbwiDtDt
<zid> XGGc6QmoEgkpSSBq0Z1cQloAJJiAN5PICvtvAXWYqttiwMEAag1YY67ZTrBZLzmAVidSgyzqNB2lJkfWHAU0u0bjMAuVddIUNHhmn3RNGm6spK3SHtn2smcTJhd0iCQGIM66SR6q0foTg7ow6XBi7dlLrsotlQjMyfJgLczydVZsoG92JBmgjFYa3bUBGZ2YAsWGknxM8OPDXTdRL0Mv38mawLVy5hhdVrdxsnyN5hc6y3c3Iy3FcEmNMtKi9Umx2Wkopb0Gq7SxP5PacHDBsz27t2+7WkLW7jWsyKo1zlC0SN8CgbpBgmt4u6tzq8z9o9WrKnyihjAYkjtM86+zcCDC7RxNy2mGw6YC6DYhx16XBaaWVsyq7NcXKbfagyxMkzQg+JVr0K+
<sbalmos> holy
<zid> dURLaN9ZbSLaDDubJnHp0OfaLJgfnTKWxsG9dzOgULJMsd+vACSdZG7WDU+10SvBVa41q0CCT1r5csEiIAIbTKd/0wN81J2vhLmHtZrV5gpYloAU5mUDfqdy8xBHPWhguWMsSx5kkn2mqxzc1aar4CzwUZN9nbQX4R9ldVZzrdzlQbgQue3GoZm01JPmjeOA3tYDaGI6wphFKq5YgMQ5tLu0ZhlTzomJMDUneLWdFB72+JrSsHg/yaylsKxukBnCQWLncuu4AZgDuGV250vK9Hu3wnwDjTl7UMrsfEIetusLkkZmzMxHLMWAMcNNBW5dHf0az6C/Csy2XYvaLdQBHVgcrFwCwOjzx45hpvHKtM6Oz+TWfQX4U3BJ1vX2F5ElwZ15RdoMl64
<geist> ahahaa
<geist> IMAGE FAIL
<sbalmos> lol
* geist points to the corner
<zid> google images uses base64 then transparently swaps the image in for the hotlinked version when it loads
<zid> and I hot my load too early sorry
<zid> shot*
<sbalmos> how hot was the hotlink?
<geist> yeah i do like the whole 'embed the image directly' thing (except it's probably a security nightmare) but it doth not work on irc
<zid> That's the hot sauce I was eating, anyway
<zid> it's scotch bonnets mashed up and put into a bottle
<sbalmos> you get a good diablo sauce from southern Italy, add some more red chili flake, it's pretty good
<geist> in the fridge i have some bottle of yucateca green sauce i think. it's too hot to use
<zid> isn't that just mashed jalapenos?
<zid> (apologies for lack of nyo)
<sbalmos> dammit, now I'm going to have to go and get some habaneros this weekend. I've got two fresh mangos left I can dice up and make fresh mango habanero sauce with
<bslsk05> ​redirect -> www.amazon.com: Amazon.com : El Yucateco Green Hot Sauce Bottle, Chile Habanero, 8 Ounce : Hot Sauces : Grocery & Gourmet Food
<zid> ah that'd be fairly hot then yea
<geist> it's beyond my ability to handle hot
<sbalmos> yeah, straight habanero?
<zid> habanero is ~250K scovilles, scotch bonnet is ~450k
<zid> similar ballpark, it's fairly log scale in practice
<geist> yah i'm totally willing to admit i have a limit
<zid> you can only hurt SO much before more hurt is no different
<sbalmos> yup
<geist> i'm more of a tasty hot, like cholula sauce
<sbalmos> geist: that's exactly why I love harissa
<zid> so yea, if you want an idea of what happened, I got a big blob of your nice green sauce on my tongue, and it had a lump that was especially extra hot
<zid> then double it
<geist> sauce is totally getting triggered left and right now
<zid> hopefully
* geist waves at sauce
<zid> man, I want more samyang buldak now
<zid> I paid over the odds for some off amazon
<zid> they were nice, but not £1.50 a pot nice
<sbalmos> leftover chicken pad thai this evening. with extra hot chili oil. ;)
<zid> hottest thing I've ever eaten was some chocolate that claimed it was 4 million
<geist> heh i think because of someone here i ended up buying off amazon a few jars of uh what was that
<geist> it was some little sauce, not HP sauce (which is very british)
<sbalmos> zid: is that the one that has like ground up bhuk joloka or whatever it is
<sbalmos> ?
<geist> but some sort of weird. hard to describe thing
<geist> like the vegemite of uk
<zid> there's a bunch, it's cheap to make and sells at a premium
<bslsk05> ​firebox.com: Instant Regret Chilli Chocolate | FIREBOX®
<zid> sorry, 6.4 million
<zid> It's just got extract added to the chocolate mix
<geist> reminds me i do recommend Lao Gan chili
<zid> geist: marmite?
<geist> zid: ugh. crap going blank. lemme find it
<zid> vegemite is the aus version of marmite, at least
<geist> it was gross was the result, not vegemite. i honestly kinda like that, have a jar on the counter
<zid> "Marmite should be stored in the dark and kept cool" This is to stop it hatching.
<sbalmos> zid: I can feel my eyes watering and the throat closing up just reading that chocolate's description
<zid> It's actually pretty good
<zid> chocolate has a lot of fat so it's surprisingly easy to eat
<geist> well, i'm going blank, i'll have to check when i get home. not getting a hit off my amazon order list either
<geist> it's some sort of pickled thing
<zid> off to google "weird british pickled thing"
<geist> got a lot of chunks in it, etc. i dunno, acquired taste
<geist> branston pickle!
<zid> picalli
<zid> oh branston pickle, nice
<zid> smooth or chunky?
<geist> i think it's chunky. i dunno i think that's kinda acquired taste
<zid> It's basically onion chutney
<geist> but i think it was somewhere here, probably you, that recommended it
<geist> probably the onion part that turns me off. i'm not a big onion fan. cooked is fine, but as a flavor its not my thing
<sbalmos> not one for French Onion soup then?
<zid> I like onion/garlic a lot
[itchyjunk] has joined #osdev
<geist> i think cooked into a think it's okay, though french onion soup is indeed pushing it
<geist> but raw onion, like on a hamburger, dominates the flavor for me
<sbalmos> I can't do avocado / guac or deviled eggs
<geist> deviled eggs i was surprised to hear is not a universally loved thing, but i heard this somewhere else too
<geist> like it really isn't cool for a lot of folks
<zid> never had one, but I also don't like egg whites much
<geist> fair
<geist> same with raw tomatoes which i always loved but turns out lots of people really dont like
<zid> I love the goo in a tomato
<zid> the flesh is just neutral
<geist> a little bit of salt i think makes it great
<sbalmos> oh yeah
<sbalmos> actually just a little garlic salt
[itchyjunk] has quit [Read error: Connection reset by peer]
<sbalmos> deviled eggs, it's the smell. texture I could probably tolerate, but the smell. *shudder*
<sbalmos> how about eggplant?
<zid> If it grows out of the ground, assume I don't like it until proven otherwise basically
<clever> sbalmos: https://xkcd.com/2593/
<bslsk05> ​xkcd - Deviled Eggs
<zid> okay maybe I want one just to try the demon egg
<zid> if I slip maybe I'll die
<kof123> the devil egg hatched the delicous devil squares...one can have fun with this lol
<kof123> *delicious
<bslsk05> ​old.reddit.com: Prepare for a short and tragic campaign! : dndmemes
<sbalmos> demon egg! lol yeah
<sbalmos> radioactive yolk
srjek has quit [Ping timeout: 255 seconds]
spikeheron has quit [Ping timeout: 248 seconds]
dutch has joined #osdev
xenos1984 has quit [Quit: Leaving.]
smach has quit [Remote host closed the connection]
bauen1 has quit [Ping timeout: 256 seconds]
smach has joined #osdev
smach has quit [Remote host closed the connection]
smach has joined #osdev
k8yun has quit [Quit: Leaving]
k8yun has joined #osdev
k8yun has quit [Remote host closed the connection]
gildasio has quit [Ping timeout: 268 seconds]
bradd has quit [Remote host closed the connection]
the_lanetly_052 has joined #osdev
bradd has joined #osdev
Terlisimo has quit [Quit: Connection reset by beer]
Terlisimo has joined #osdev
[itchyjunk] has joined #osdev
[itchyjunk] has quit [Read error: Connection reset by peer]
Vercas68 has joined #osdev
Vercas6 has quit [Ping timeout: 268 seconds]
Vercas68 is now known as Vercas6
bauen1 has joined #osdev
the_lanetly_052 has quit [Ping timeout: 252 seconds]
bauen1 has quit [Ping timeout: 256 seconds]
bauen1 has joined #osdev
dionys has joined #osdev
GeDaMo has joined #osdev
the_lanetly_052 has joined #osdev
bauen1 has quit [Ping timeout: 252 seconds]
smach has quit [Read error: Connection reset by peer]
gog` has joined #osdev
smach has joined #osdev
sav_ has joined #osdev
sav_ has quit [Client Quit]
Vercas6 has quit [Remote host closed the connection]
Vercas6 has joined #osdev
freakazoid333 has quit [Ping timeout: 244 seconds]
Vercas6 has quit [Remote host closed the connection]
Vercas6 has joined #osdev
ghee has joined #osdev
heat has joined #osdev
<heat> wake up honey, new rfc just dropped
<heat> rfc793(tcp) just got obsoleted by 9293
<heat> which has 793 plus a bunch of extensions, path mtu discovery, etc, it's great
bauen1 has joined #osdev
gildasio has joined #osdev
eroux has quit [Ping timeout: 268 seconds]
<sham1> It's not often that a core protocol like TCP gets updated
<sham1> Exciting
<heat> yes
<heat> nothing really changed, it's just a consolidated, rewritten rfc of every other important tcp rfc
gog` has quit [Ping timeout: 248 seconds]
gog has quit [Ping timeout: 252 seconds]
gildasio has quit [Ping timeout: 268 seconds]
dh` has quit [Ping timeout: 256 seconds]
smach has quit [Read error: Connection reset by peer]
smach has joined #osdev
gildasio has joined #osdev
Vercas6 has quit [Quit: Ping timeout (120 seconds)]
Vercas6 has joined #osdev
<zid> Now that's what I call TCP '22
<mrvn> I'm missing the evil bit in the header :)
smach has quit []
[itchyjunk] has joined #osdev
nyah has joined #osdev
scoobydoo has quit [Read error: Connection timed out]
scoobydoo has joined #osdev
gog has joined #osdev
srjek has joined #osdev
smach has joined #osdev
foudfou_ has joined #osdev
foudfou has quit [Ping timeout: 268 seconds]
Vercas6 has quit [Quit: Ping timeout (120 seconds)]
Vercas6 has joined #osdev
ghee has joined #osdev
ghee has quit [Changing host]
gildasio has quit [Quit: WeeChat 3.6]
foudfou has joined #osdev
foudfou_ has quit [Quit: Bye]
gildasio has joined #osdev
srjek has quit [Ping timeout: 255 seconds]
xenos1984 has joined #osdev
Vercas6 has quit [Quit: Ping timeout (120 seconds)]
Vercas6 has joined #osdev
eroux has joined #osdev
Vercas6 has quit [Quit: Ping timeout (120 seconds)]
freakazoid333 has joined #osdev
gog has quit [Read error: Connection reset by peer]
gog` has joined #osdev
opal has quit [Remote host closed the connection]
opal has joined #osdev
gog` has quit [Ping timeout: 256 seconds]
atilla has joined #osdev
<atilla> what's up my IDT setup strugglers
<heat> do you need help with your idt
<atilla> there's no such thing on risc-v luckily
<heat> riscv is a trashy platform
<heat> simple = cringe
gog` has joined #osdev
<heat> join real architectures and get overwhelmed under 40 years of backwards compatibility
<heat> legacy = enterprise-grade
gog` has quit [Ping timeout: 248 seconds]
opal has quit [Remote host closed the connection]
gog` has joined #osdev
<atilla> kek
opal has joined #osdev
atilla has quit [Ping timeout: 256 seconds]
opal has quit [Remote host closed the connection]
opal has joined #osdev
<gog`> fr fr
<mjg> heat: you seem a little jaded for early 20s
<bslsk05> ​www.jsoftware.com: An Implementation of J -- Incunabulum
dutch has quit [Quit: WeeChat 3.0]
gog` has quit [Ping timeout: 248 seconds]
dh` has joined #osdev
<zid> gog I am too old for this
joe9 has joined #osdev
ghee has quit [Quit: EOF]
spikeheron has joined #osdev
gog has joined #osdev
opal has quit [Ping timeout: 268 seconds]
saltd has joined #osdev
dormito has quit [Ping timeout: 268 seconds]
opal has joined #osdev
<ddevault> does anyone have a reference implementation of a simple buddy allocator to point to
saltd has quit [Read error: Connection reset by peer]
<mjg> why do you want a buddy allocator/
<ddevault> well
<ddevault> I initially had a watermark allocator, which is fine for the start but has Problems
<ddevault> now I have a free list, which is better but makes allocating continuous ranges of physical memory more challenging
<ddevault> buddy allocator seems like a good next step
scoobydoo has quit [Read error: Connection timed out]
<ddevault> but I still don't fully understand the concept, so some code to reference would be nice
scoobydoo has joined #osdev
<dh`> iirc malloc in the original 4.4 was a buddy allocator
<dh`> got ripped out later because it sucked
<mjg> ddevault: have you read the slab paper by bonwick? (and vmem on top of it)
<ddevault> nope, thanks for the ref
<mjg> that's the classic
<ThinkT510> doesn't jemalloc have a buddy allocator? https://github.com/jemalloc/jemalloc
<ddevault> *simple*, ThinkT510
<mjg> i don't know what jemalloc is doing tbh
<mjg> but i probably should
<heat> mjg, why am i jaded
<ddevault> hm, this does not seem to describe a page allocator
<heat> its not like i've spent a considerable portion of my last 7 years writing an OS
<heat> now *those* people are jaded
<heat> ddevault, why do you need a reference impl?
<ddevault> just to help me wrap my head around the concept and its implementation
<heat> I had one in the good old days but I don't trust it too much and it's burried in my commit history
<ddevault> I don't intend to actually use the code
<ddevault> just read it
<heat> the basic implementation is that you have a N lists of order N pages
<heat> then a bitmap to know when you can merge things back to N + 1
<heat> the logic goes like "try order 0, if there's no page, go to order 1 and split it into two order 0 pages"
<heat> well, not *a* bitmap, but a bitmap per order
<ddevault> where is that bitmap generally stored?
<heat> in memory you need to allocate before your page allocator is up
<ddevault> dynamic memory? or static
<heat> congrats, you hit the hell that is boot memory allocators
<heat> dynamic of course
<ddevault> I mean I've been here before
<geist> usualy you can store the data structure to track an arena of physica pages in the pages themselves
<ddevault> and it is a hell indeed, but one I am prepared for
<geist> or at least that's the general strategy i have taken
<ddevault> I wonder if I can combine a free list and a buddy allocator
<heat> buddy allocators are just a bunch of freelists plus a bitmap
<zid> I have freelists and bitmaps
<zid> but I never actually hooked them up :D
<geist> buddy alocator seems a bit advanced for this stage of the project. if this is just a PMM, then a simple O(1) list or bitmap is generally fine
<geist> since you usualy dont care about fragmentation physically
<ddevault> well, I just want a design that meets my goals
<zid> I just carefully organized my DMA so that I could use non-overlapping pages
<heat> yes but it ends up affecting the rest of your mm design
<zid> 4k TX queues etc
<ddevault> which, to be specific, are: allocating pages, continuous ranges of pages, and freeing pages
<ddevault> and, ideally, something I can add huge pages to later on
<heat> linux's mm works because it rests on the fact that allocating physically contiguous chunks is fast and easy
<ddevault> my current free list design can allocate and free pages, but cannot allocate continuous pages or huge pages
<bslsk05> ​twitter: <ChevyRay> nobody ever mentions the greatest benefit of not using source control: everything can be lost completely. the true best outcome. finally, it's gone, we're free.
<geist> ddevault: indeed, but i'm not so sure it's worth pivoting your whole design around
<ddevault> well, I definitely need continuous pages
<geist> even a bitmap one you can allocate contiguous, it's just a slow operation
<ddevault> and I'd prefer not to do a bitmap
<geist> but since it's orobably rare that's probably fine
<geist> okay, a linked list then, that's what i have always done
<geist> an array of per page structures, that are then also stuffed in a free list
<ddevault> linked list also makes it hard to to continuous allocations :<
<geist> pop one off for a page, but to allocate contig you walk through the array
<ddevault> hm
<heat> i did what geist does
<heat> it just works(tm)
<zid> zidlist ftw
<geist> gotta go, bbiab
<ddevault> works if you're careful to avoid multi-page structures crossing page table boundaries
<heat> allocating contiguous pages is shit but oh well
<zid> a zidlist is where you allocate a linked list out of an array (or dynamic array) of structs
<heat> I only allocate them when I really need to
<ddevault> the alternative is making the kernel page tables a bit more sophisticated
<ddevault> so that I can map non-continuous pages continuously
<ddevault> but I'm not in love with that idea
<zid> what do you need contig pages for, DMA?
<ddevault> device memory is a much worse can of worms
<ddevault> this is just because some of my data structures exceed a page in length and I'd like to be able to work with them through a regular old pointer
<ddevault> and presently my kernel uses a fixed set of page tables
toluene has joined #osdev
saltd has joined #osdev
xenos1984 has quit [Read error: Connection reset by peer]
dude12312414 has joined #osdev
<heat> gog, wtf is that program and why is that so fresh sheeeeeesh bruh on god frfr
xenos1984 has joined #osdev
the_lanetly_052 has quit [Ping timeout: 256 seconds]
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
saltd has quit [Remote host closed the connection]
<geist> ddevault: yeah that is an issue. if yo have a physmap (all of physical memory mapped i the kernel) and you allocate data structures out of it then it's hard to have them cross boundaries
<geist> physmaps work great for things like page tables, since it doesn't matter if they're scattered around
<geist> and you can directly access any page table in any aspace with just a simple transformation of physical -> physmap
<geist> this is why i dont lean on things like recursive page tables, because the physmap solves it for all aspaces simultaneously on all architectures
<geist> but... data structures that are large are a problem. for those you really gotta pull them out and make a virtual mapping
<zid> I do both cus weird
<geist> zircon does both too, actually
<geist> the heap still lives n the physmap and thus still leans on contig allocations
saltd has joined #osdev
<geist> though we have a general rule that you can't malloc() > 4K data structures so the heap can expand one page at a time
<zid> I like like how simple the page table code is if you use recursive
<zid> s/like/just
<geist> yeah i just cant get behind it because its instrinsically an x86 only thing anyway
<geist> so though it's cute i have to generically solve the problem for non x86
<geist> and once you generically solve it, it has very little advantage outside of early bootstrapping
<geist> also i think the TLB shootdown issues on x86 are kinda swept under the rug a bit. for a SMP machine i think it's pretty expensive to maintain these recursive mappings
<zid> why would the recursive mapping way need more tlb shotdowns, are you likely to change the permissions on the pages in the pagetable?
<zid> rather than the pages they're describing
<geist> as you're mapping and unmapping inner page tables you'd have to do the TLB shootdowns on the recursive mapping itself
<zid> yea I am asking why you would need to do the shootdowns on the recursive mapping at all
<geist> since those end up being interpreted as leaf page tabe entries
<geist> then you have to shoot those down as you remove inner page tables
<geist> but a lot of that depends on the also complicated probem of how one does recursive mappings in a SMP world. does each cpu get a slot?
<geist> do you have to pin the current thread on a cpu while fiddling with it?
<geist> when you stop fidding with it and free the slot do you have to do a local TLB shootdown before you can reuse the slot? etc
<geist> it gets fairly complicated pretty quickly
<geist> i think it tips over the threshold of not worth the trouble pretty quickly
<geist> i think for a UP x86 system it's not a bad strategy, since none of these TLB shootdown things become that complicated. maybe you have to do a few extra TLB invalidates when removing an inner page table, but they're local
<geist> you might have to deal with having two slots for this stuff: the current aspace and an aternate one, since it's fairly common to manipulate a 'foreign' aspace whie one is active
<geist> also a thing the physmap solution has no probem with, sicne there's no notoin of a live aspace vs a nonactie. they're all equally visible
<zid> (note none of this will make sense until I figure out the answer to the question I asked earlier)
<geist> which is?
<zid> why would you ever need to invplg the recursive mapping across cpus to begin with
<geist> okay, start with without having multipe cpus
<geist> if you are UP, you do note that you have to do an invlpg when you detacth a page table itsef right?
<zid> sure, otherwise the TLB would give me a hit instead of walking it properly
<zid> and it relies on it being a proper walk every time to work
<geist> so if you're SMP and they're mapped into the kernel, you'd have to shootdown cross cpu
<zid> you skipped the part that answers my question there though
<geist> *unless* you make the recursive mapping intrinsically single cpu
wootehfoot has joined #osdev
<zid> what's causing other cpus to care
<geist> being mapped into the kernel aspace
<zid> they have their own valid/invalid mappings
<zid> and we're *always* invplging anyway
<geist> well, not when fiddling with page tabe entries
<geist> this is a new thing you have to do with the recursive stuff
<zid> I need to distribute the info that the mappings changed somehow though, whether I changed it via recursion or a direct magic bullet write
<geist> basically you want to avoid manipuating the kernel aspace like the plague if you can, because it invoves gobal TB invalidates
<geist> ah no, the difference is whether or not you have to do it for *all* cpus, or just cpus that currently have the aspace mapped
<geist> since the latter is usually far lesser than the former, it's a huge win
<zid> heh the onion keeps growing
GeDaMo has quit [Quit: A program is just a bunch of functions in a trenchcoat.]
<geist> in the case of unmapping/protecting a regular page in some random aspace, any serious system at least keeps a bitmap of which cpus have the aspace active
<geist> and ony shootdown on this
<zid> Not seeing it
<geist> but... for stuff ike the recursive table which is intrinsically mapped into the kernel you now expose *all* of the cpus to the mappings
<zid> why do cpus without these page tables loaded care?
<geist> i think we're just not on the same page here
<geist> probably a different set of base assumptions about how stuff works
<geist> not saying the recursive thing cant be made to work efficiently, but if you follow it's trail down to all the usual details it ends up with a few edge cases that are either nasty or require restructuring things differently than if you hadn't use recursive mappings
<zid> one cpus starts playing snake, loads cr3 with some value where [cr3+504] == cr3
<geist> and then it being x86 ony requires you now have to deal with an x86 only hack that infuences the rest of the design
<zid> other cpu starts playing monkey island, does the same, different cr3 value
<zid> why do they care about each other?
<geist> what if the cpu that is playing snake wants to modify monkey island's aspace?
<zid> Okay that's an interesting thought
<geist> that's part of this 'starts to influence the whole design' thing. now it may be that the whole upper level VM has to start knowing about 'the current aspace' vs 'not currently active' and treating them differently
<geist> i prefer designs where current and not current are equally availabe
<zid> actually I don't understand the question, what are you meaning by 'aspace' here, modifying *its* page tables remotely? That's just some random physical memory I have to map into my process then write to, isn't it?
<geist> you can, for example, swap to the target aspace, do some mmu ops, then swap back, but then that's a cr3 reload
<geist> address space. think of it as the per process object that holds all of the page tables for that process, etc
<geist> pmap in BSD parlance
<zid> yea I got what it abbreviated for, just not necessarily what you meant by it, the actual page tables, or some tracking objects or whatever
<geist> kinda both. i use aspace as the object that among other things holds the cr3
<zid> It doesn't seem important to me in the least
<zid> like.. how many times am I running CreateRemoteThread?
<geist> it's a shortcut for saying 'that whole thing'
<zid> when cheating at battlefield or whatever is all I can think of
<geist> and this is where i think we have different assumptoins about what operations are important
<geist> but that's what i was trying to express a bit a whie ago
<zid> it's important to microkernels?
<zid> cus of all the message passing stuff?
<geist> it's important to compicated VMs that are scanning page tabes that are non active
<geist> for example. it's also important to different designs that may or may not be posixy or win32y
<zid> big iron processes vs hippie free love processes :P
<geist> for zircon for example it's *extremey* important, but we build the whole design around it
<zid> yea well if you have to optimize for it you have to optimize for it
<geist> anyway, fine. i've said my peace. i just wanted to you to see that it's not always a win win
<geist> but you're not interested so i should get back to work
<zid> Saying "It's important in zircon to be able to easily access another process' page tables, and you can't even really USE recursive mapping to help you there" would have clued me in a lot better than talking about all cpu shootdowns or whatever
<zid> what
<zid> the fuck are you talking about geist
<zid> when have I ever dismissed anything you said for any other reason than that I didn't understand
<geist> well, no i was explicitly trying not to state zircon at all
<zid> because as you mentioned, it isn't my wheelhouse
<geist> you dragged it in and then wrote off the whole explanation as 'oh this is some zircon thing'
<geist> which was *not* my intention
<zid> I didn't write anything off, I said oh, is this on your mind and important to you, because of your important projects
<zid> that seems 100% reasonable to me
<geist> most OSes dont use this recursive thing because it has downsides
<geist> i was trying to generically describe some of the downsides
<geist> and plus it's x86 specific *anayway*
<geist> without trying to bring zircon into it, because i'd assume you'd say what you did
<zid> right but to actually *get* to those downsides you have to come up with a pretty specific example, and I was trying to figure out *when* that example would be important
<geist> we haven't really described how it'd work otherwise in an SMP situation
<geist> is that that each cpu intrinsicaly has the local aspace's reursive tables mapped into the same 'slot' because it's specific to the CR3?
<zid> well you'd need a second code path regardless right?
<geist> if so, does that mean you can only intrinsically manipulate the current aspace?
<geist> we that's the question, what does the second code path ook like?
<zid> the point of the recursive mapping is to abuse the MMU to do the walking code for you
<zid> so if you're talking about a process that isn't loaded, it doesn't work
<zid> so you'd need a 'walk the page tables like a normal human' version for remote ops
<geist> or for example a VM worker thread that's cycling through and evicting page tables
<geist> it could just keeep setting one active, manipuating it, moving on
<zid> cute, loading cr3 blows the tlb though sans global bits
<zid> and I don't think you want global bits set on your recursive mapping anyway
<geist> ah but you have to wak them in the recursive case too, you just dont have to do the physica -> virtual transation at every leve
<zid> so is that a problem?
<geist> you can't 'jump to the end'
<geist> so al you're really saving is the physical -> virtual lookup on every page table
<zid> jump to the end of what? what jumping and what end?
<geist> well you said 'the mmu doing the walking code for you'
<geist> but you can't let it walk all 4 levels, you have to still iterate each level, you're just doing it in the recursive mapping
<zid> you're generating virtual-virtual-addresses that let you modify virtual-addresses, by using the hw which does virtual->physical one step removed
<zid> and tricking it into treating phys as virt
<geist> yes but still have to do it per level, is my point
<geist> you can't skip directly to the last level, which would be a good win
<geist> *unless* you absolutely knew it was mapped already
<zid> yea that'd be a useful optimization sometimes I imagine
<geist> otherwise you'll get a page fault
<geist> anyway, gotta get back to work
<geist> i've managed to not convince another user of the recursive tables that it has issues :(
<zid> It obviously has issues
<zid> everything has issues
<geist> i've tried this again and again over the years, but most users of the recursive tables will hold onto them until the grave
<zid> the question is whether those are the *important* issues, to your workload/design
<geist> or eventually they figure it out
<geist> i think it fals into the same category as 'bitmap to track your page allocation'
<zid> for my workload the pagetables basically never change so whatever works tbh
<zid> so whatever's easiest to write into C is the best approach
<geist> useful for the first few stages of osdev but it eventually ends up being more trouble than its worth
<geist> sure. i just wanted you to see where some issues would happen
<zid> right you just skipped a step and really confused me
<geist> anyway, gotta meeting
<geist> bbiab
<zid> by saying you'd *have* to shoot down all cpus all the time, out of nowhere apropos of nothing
<zid> so I had to do a deep dive into the 20 mental steps that were comfortable to you, but I'd never had to deal with in my designs
<zid> then I think you got upset that I thought maybe it'd be useful for microkernels to not do that
<zid> I still don't know why though
<geist> fine.
<geist> tired of arguing about it. forget the discussion happened
<zid> okay but then you're just going to get upset again
<zid> because I still don't know what upset you
<geist> bummer.
<zid> "babe what's wrong?" "Nothing" *oh fuck*
<geist> both of us have 'get in the last word' syndrome
<geist> so we keep dragging it along
<zid> No you're just being a child
<geist> no you!
<geist> doodoohead!
<zid> I'm was being courteous and asking you nicely what I did to upset you and how I could rsolve it
<zid> you told me it was my fault and I had issues
<zid> go away
<geist> again can we just drop it?
<dh`> looking at the scroll I can't even tell what you're fighting about :-(
<geist> i just wanted a 10 minute discussion and it tipped into something personal for accidental reasons so i just pull the plug
<geist> that's all. just a misfire. life will go on. /me buys zid a beer
<mjg> can i have the last word?
<mjg> </thread>
<geist> (see, getting in the last word)
<mjg> sounds like 2, to nitpick!
<j`ey> aarch64
<geist> speaking of: one of the really nice things about arm64: its page tables are very fragile. if you corrupt one, boom you get an exception that is well detailed
<geist> so, for example, when some device dmas all over ram the kernel is frequently the canary in a bad page fault
<j`ey> I think I found a bug in qemu cos my tables were wrong but it didnt blow up
<geist> not sure qemu is as picky as real hardware is
<zid> moar nochain
<zid> nochain solves all ills
<j`ey> I had to dive into qemu code
<zid> It's an absolute panacea, an elixir of bug resolvement
<geist> a common thing that you get in the real world, especially without an mmu, is dma trashing physical ram
<j`ey> and by dive, I mean add printfs
<geist> having the kernel be very aggressive about asserting things is good. just had a bug filed internally with a stray dma caught with our PMM checker logic (expensive, not on all the time)
<geist> but basically it writes ot a known pattern to freed memory and scans for corruptions
<geist> catches a fair amount of things
<geist> looks like 24 bit pattern. probably RGB data
<j`ey> nice
<j`ey> DMAsan
<geist> yah the proper solution is to have an iommu, but sadly most consumer ARM hardware still doesn't seem to have one
<geist> i think this is partially ARMs fault for making it non mandatory, and then their design (SMMU) is hella complicated and probably expensive in hardware
<geist> and thus vendors dont stuff it
<zid> expensive devkit version with an iommu for debugging sounds useful though
<mjg> geist: so you recently linked your memcpy or memmove for 32-bit arm
<mjg> would be curious to bench it against the crap in freebsd
<mjg> [although, not an arm erson, person that was 64 bit?]
<mjg> s/person/perhaps/
<geist> yeah that ended up being the darwin version (i wrote it when i was at apple)
<geist> but arm64 has a completely different set of constraints, so arm64 memcpyes look totally different
<geist> and i wasn't at apple at the time the 64bit world came along
<mjg> do you have any board which can run that code/
<geist> oh probably. but also i think that was born in an era when unaligned stuff mattered more than it does not
<geist> so if i ran it on say a modern cortx-a53 or a72 in 32bit mode, it may be effectively 'too powerful'
<geist> and just to be clear which code are you talking about? the arm32 assembly?
<mjg> yea
<mjg> bcopy.s
<geist> as a side note they have an arm64 version right next to it, up and over a level in the file heirarchy
<geist> i didn't write it, but it looks like it's been tuned at least
<mjg> maybe that should take cortex strings
<mjg> interestingly they have copy pasted the *terrible* bsd routines
<mjg> for amd64
<geist> yah i didn't look too closely at it
<geist> maybe they runtime patch it
<dh`> I'm glad someone looks after micro-optimizations because I usually just can't bring myself to care
<dh`> :-p
<mjg> one could argue that's passe in the current cpu vuln landscape
srjek has joined #osdev
scoobydoo has quit [Read error: Connection timed out]
scoobydoo has joined #osdev
<geist> yeah, and/or modern cpus tend to be pretty fast at plain ass code
<geist> though there's stillr oom to eek out a bit for memcopies and whatnot
wootehfoot has quit [Ping timeout: 256 seconds]
thatcher has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
leah_ has joined #osdev
dormito has joined #osdev
srjek has quit [Quit: Leaving]
ghee has joined #osdev
gildasio has quit [Quit: WeeChat 3.6]
ghee has quit [Quit: EOF]
wereii has quit [Quit: ZNC - https://znc.in]
ghee has joined #osdev
wereii has joined #osdev