Contributed by tbert on from the dont-go-in-the-subway dept.
Bob Beck(beck@) provides us with a...colorful...description of his work in the buffer cache:
I've been crafting a fix to the problem of the buffer cache allowing unlimited writes to be buffered up inside it. in the process I've found and fixed an issue of io starvation with the algorithm in disksort(). With the two of these together, systems perform much better under heavy io load without locking up. I watched theo basically impale his laptop on hundreds of core dumping processes which were also larger than memory size so he was also swapping while dumping hundreds of core files. Incredibly, after several hours the machine managed to slowly Kegel it's way back up the impaling pole and survive.
I've also been working on looking at some early diffs for incorporting some more filesystem functionality (write ahead physical block logging) chasing performance issues with softdep, none of which will get finished here. I'm not done yet, I may chase my way into some userland stuff and spamd/authpf maintenance.
Jasper Lievisse Adriaanse(jasper@) was a busy bee, cycling through multiple projects:
For this hackathon I had one item on my list that I really needed to finish, which was importing lua 5.2 into the ports tree and adjusting the tree to deal with multiple versions of lua (5.2 is incompatible with 5.1). But the thing with hackathons is that you'll never just do what you intend to do, this was true for g2k12 as well. Thanks to mpi@ we made huge progress in a different area, OpenGL/Clutter. We had been observing a bug in Mesa for years now which prevented us from updating Clutter, and importing the last misisng piece of GNOME3, the Shell. So within the first two days of the hackathon, Antoine committed the Clutter update we had been working on with Robert for a few years, and I finally imported GNOME shell. As well as committing some outstanding updates for other ports which were now unblocked.
After this chunk of work was taken care of I finally finished the Lua work in ports and started poking the DRM bits needed for my Ivybridge laptop in order to use the Intel X.org driver instead of VESA. Currently not too much progress, hopefuly in the future I'll have more to report on this.
espie@ has been doing some major cleanups of our own libtool(1) implementation, uncovering some interesting design/behaviour "quirks". Over the course of the week I helped a bit with cleaning stuff up a bit and reporting regressions as I was doing continious bulk builds during the course of the hackathon. Which allowed us to observe and fix bugs fairly quickly.
Finally, a while ago I revived tedu@'s diff to add tinyscheme support our mg(1) editor. After talking to nicm@ we figured that using Lua instead of Scheme would be an easier choice in order to extended mg, and to replace some existing C code with Lua. Having Lua in base would also allow for extending tmux(1) with Lua and various other neat applications of the language. So in order to prepare for such a move if it were to hapen eventually I spend some time on preparing Lua 5.2 for import into the base system. Please note that it's far from ready and may not even happen at all.
Finally, Brandon Mercer(bmercer@) tells us about working on a new architecture:
I worked on the panda porting efforts some more. Arm'd[groan -ed] with a diff from miod@ it only took a few tweaks to get the kernel booting into userland. By borrowing the zaurus binaries and copying the src tree onto the SD card I was able to do a native build of the kernel. Currently it's just in SP mode and takes about 24 minutes to build a kernel. The really good news about all this is that I was able to turn on the cache and have things still function properly. Slowly I'm sorting out how to support the beagle and panda and figuring out what can be shared and what can't. There is still plenty of work to be done.
(Comments are closed)