<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