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=osdev2&y=21&m=10&d=23
00:01:00 <geist> oh oops
00:01:00 <geist> also if you accidentally used APIC ID 0, it's pretty much guaranteed to be BSP
00:01:00 <geist> id wrap, truncation, etc
00:05:00 <geist> though yeah getting into the AP code from reset is odd
01:12:00 <kazinsal> Hmm. I'm hesitant to call this a VMware bug, because I'm generally hesitant to blame anything other than my own code, but I can't reproduce this in VirtualBox or QEMU (with or without KVM). Haven't tried on Hyper-V (don't have a Hyper-V box handy) or real hardware so time to keep digging.
02:33:00 <geist> nice, finally around to setting up a private 10gbe link between my VM server and my NAS box
02:33:00 <geist> definitely seems to be pretty speedy. maxes out the disks at 350MB/sec and if it's cached on the NAS seems to push about 700 over NFS
02:35:00 <geist> basically a pair of 10gbe pcie-4 copper nics with a cat 6 3 foot wire
02:35:00 <geist> ACQ-107 chipset, which seems decent enough for the price (about $100)
02:37:00 <geist> i might regret using copper and not SFP+ though, since it seems most switches are SFP+
02:37:00 <geist> if i ever get around to adding a switch in the middle of it
02:41:00 <geist> in that case SFP+ kinda makes some sense. cheaper switch, pay by the connection for the transceiver
02:55:00 <kazinsal> nice. SFP+ transcievers for 10GBASE-T are pretty inexpensive now
02:56:00 <geist> yah looks like most relatively inexpensive 10gbe switches are mostly just a pile of SFP+s
02:59:00 <kazinsal> hmm, generic SFP+ 10GBASE-T transcievers are about $65 USD now. not as inexpensive as I thought
03:00:00 <kazinsal> 10GBASE-SR fibre transcievers are $20
03:00:00 <geist> yah that's possibly why 10gbase-t switches are expensive
03:01:00 <geist> sounds like the per port hardware is pretty hard to make
03:01:00 <geist> whereas dumping it onto fiber may be simpler
03:02:00 <kazinsal> lot higher wattage and more complex I think
03:03:00 <geist> yah i read there's a fair amount of compelxity and ECC and retransmitting and whatnot to get 10gbe over copper
03:03:00 <geist> so lots of asic there to back it up
03:03:00 <geist> may be tossing itonto fiber is much less complicated silicon wise
03:03:00 <kazinsal> yeah, the line coding for 10GBASE-T is way more complex
03:16:00 <klange> Ah, well. So the cause here was actually the terminal scrollback eating all of memory, combined with an oversight on how I'm mapping physical memory for arbitrary modification.
03:43:00 <klange> Also general problems with my heap implementation showing up in both the kernel and userspace. I really should write a new malloc - this one predates the beginning of the ToaruOS project.
04:03:00 <geist> yah i need to finally write a real driver model for LK
04:03:00 <geist> but there are sooo many existing drivers
04:03:00 <geist> tiny little one off things, but getting them all converted is going to be a pain
04:15:00 <moon-child> geist: niice
04:16:00 <moon-child> i only have a 2.5gbps thing
04:31:00 <klange> The key problem with my malloc is that it will never release memory, and if you get it to fragment just right you can manage to be constantly allocating more memory while not actually using much.
04:31:00 <klange> In userspace that is resolvable by just killing the process, but I use the same heap implementation in the kernel, where there's no good fix.
04:32:00 <geist> i do recommend always having a really dumb simple one to use for things liek bootloaders and whatnot
04:32:00 <geist> i wrote a super simple default one for LK years ago that just uses a linked list of free blocks that has been useful to plonk into random projects
04:32:00 <klange> It's actually a fairly good malloc if you can ignore that flaw.
04:33:00 <klange> The main source of its issues is that it was written for uni coursework that stipulated system mechanisms and also there were a competition with a particular test suite, so it's kinda tuned for that environment.
04:34:00 <klange> And ten years ago I gave up on improving it. It's thread safe by heavy locking, it never reclaims memory, it only uses sbrk()... but it does okay with alignment requirements, has a good binning strategy for small allocations, and it's faster than glibc's default at least.
04:35:00 <klange> It's actually really good if you have lots of small allocations but don't really know how big they'll be. It's not great at large allocations, and that's the main source of issues with fragmentation - you start allocating buffers that are bigger than the max bin size and all hell breaks loose.
04:36:00 <klange> I had a huge TODO that I think has lived as a big #if 0'd chunk of code to have it merge neighboring unused regions.
04:37:00 <klange> Really, I need to get off my ass on implementing a proper mmap and stop relying on a single heap break. At least with the kernel this should be more straightforward, and in fact I do quite a lot of direct page allocation instead of going to heap, where I can.
04:38:00 <klange> I did a few more tests with this loopback and, uh, actually the problem is a combination of things, but I think the biggest one is that I didn't put a limit on queue sizes and it can send much faster than it can receive in most situations.
04:39:00 <klange> So I sent a few million UDP packets and before you know it you've got the kernel heap moved a gigabyte up and that's never going back to the available memory pool and you better hope you want more allocations of the same size when they finall get cleared out...
04:39:00 <klange> This reminds me that I do something terribly silly in one of my userspace apps: The desktop provider will kill itself after changing the wallpaper.
04:40:00 <klange> It does this intentionally. it loads the new wallpaper, does a transition animation, then restarts itself (I think I just re-exec it), which ensures the memory from the old wallpaper is released.
04:41:00 <klange> The compositor handles this okay since it never actually clears the screen, so you just get a tiny bit of ghosting from things being redraw on top of themselves in the framebuffer before the new wallpaper client starts up again.
05:30:00 <vai> hi all
05:30:00 <vai> working on my pet project