qyliss changed the topic of #spectrum to: A compartmentalized operating system | https://spectrum-os.org/ | Logs: https://logs.spectrum-os.org/spectrum/
<qyliss> lol, forgot the week number
<cole-h> Just title it "This Week in Spectrum, N+1" from now on, and it'll always be right :P
<qyliss> public-inbox likes to think emails with identical subjects are part of the same thread (to compensate for broken mailers), so that's why I include the week number in TWiS
<qyliss> Otherwise it would end up looking like one ginormous thread
<cole-h> Oh, I see.
<qyliss> I'm sure I could disable that, but the fact that it does it by default suggests there are lots of broken mailers out there
tilpner_ has joined #spectrum
tilpner has quit [Ping timeout: 246 seconds]
tilpner_ is now known as tilpner
<MichaelRaskin> I wonder if there is anything useful to look at in how Genode does drivers-in-Linux-VMs
MichaelRaskin has quit [Quit: MichaelRaskin]
cole-h has quit [Quit: Goodbye]
ghavil has quit [Ping timeout: 258 seconds]
ghavil has joined #spectrum
maxdevjs has joined #spectrum
maxdevjs has quit [Remote host closed the connection]
alj[m] has joined #spectrum
cation21 has joined #spectrum
alj[m] has quit [Client Quit]
alj[m] has joined #spectrum
<alj[m]> TWIS was a good read. I'm looking forward to what you're ending up doing for the hardware isolation
puckipedia has joined #spectrum
mearon has quit [*.net *.split]
lukegb has quit [*.net *.split]
puck has quit [Quit: nya]
puckipedia is now known as puck
lukegb has joined #spectrum
mearon has joined #spectrum
cole-h has joined #spectrum
jb55 has quit [Ping timeout: 240 seconds]
jb55 has joined #spectrum
<samueldr> (from backlog) number TWIS using YYYY-WW where WW is the ISO week date :)
<qyliss> samueldr: that's what I do!
<qyliss> except this week I forgot to actually fill that in
<samueldr> oh
<qyliss> so the subject line ends in ", ", before where I should have pasted this week's date :)
<samueldr> I thought you were going incrementally from one (sorry, not been reading them)
<samueldr> oh, indeed you do
<samueldr> great thought!
nicoo has quit [Remote host closed the connection]
nicoo has joined #spectrum
jb55 has quit [Remote host closed the connection]
jb55 has joined #spectrum
<Irenes[m]> I just read the latest TWIS
<Irenes[m]> you asked for advice on memory allocators
<Irenes[m]> I believe slab allocators are the state of the art. there are some papers about the Linux kernel's implementation.
<Irenes[m]> any generalizations you're able to make about the sizes of the buffers you allocate are going to be extremely relevant and worthwhile
<Irenes[m]> for example, if what you're allocating is really working space for other applications to do their own allocation within... then it's probably at least a few K minimum size? if so, that's very significant
<Irenes[m]> userspace allocators such as malloc() are heavily constrained by the fact that a lot of their usage is space for strings and stuff, in the general range of 1-128 bytes
<Irenes[m]> they need to prioritize good performance for that above everything else
<Irenes[m]> you probably don't have that constraint
<Irenes[m]> also you should figure out whether you need to support reallocating existing buffers to different sizes. that is a significant amount of additional work to support.
<Irenes[m]> oh, another important thing to study is how frequent allocations are
<Irenes[m]> optimizing for thousands per second is very different from optimizing for one every ten minutes