Contributed by tbert on from the tuff-sheet dept.
Christiano Haesbaert(haesbaert@) describes his work towards reducing lock contention in the scheduler:
I arrived at g2k12 with a few items on my mind:
- commit some nc diffs from tech@.
- finish my sched_setpriority() diff.
- clean up scheduler code.
- discuss the idea of removing the global SCHED_LOCK in favor of per-proc and per-cpu locks.
On Saturday I managed to take care of the nc diffs, which was ok; some simple commits.
On Sunday I was really wasted since I had been travelling for almost 3 days, so I didn't do much, but still manage to work on the sched_setpiority diff and got some great feedback from guenther@.
On Monday I started discussing what I wanted to do about the SCHED_LOCK with blambert@. This was very productive, at that time I knew what I wanted to do, but was pretty unsure on the best approach to the problem, so after discussing for a couple of hours we decided to take a look at NetBSD code.
To my pleasant surprise, what they were doing wasn't very far from my original idea, but it was plain smarter; I spent the next two days mapping their code and trying to figure out what they did. By Wednesday I understood most of it, so blambert@ and I sat down for a long talk about the subject; we were somehow convinced their approach was good enough, but as OpenBSD developers we wanted to do it simpler and cleaner. At this time we also involved master guenther@, who, as usual, understood it all in less than 1 minute and pointed out some ideas and paths to follow. Those discussions were *very* *very* productive, and that is what hackathons are for after all.
Also, on Tuesday mikeb@ had told me about ajacoutot@ IPI storm, he told me it was an IPI NOP, and, while reading the scheduler code and after directing a question to guenther@ about signals, I ended up finding the problem; it was a one-liner bug, but quite nasty.
The next days I spent writing some code snippets and discussing them with blambert@, he also made this sweet ascii chart about all the state transitions we needed, and which locks we would use and so on. So now I'm onto this big project which I intend to move forward; although it's a hard path, I feel we might be on the right track here.
I just want to thank blambert@ and guenther@ for devoting so much time with my inquiries, it was really awesome.
And of course, a big thanks to robert@ who was there every time we needed something (and that was pretty much always for me).
Martin Pieuchot(mpi@) helped make your desktop more lickable:
I went to g2k12 with some macppc and USB items on my TODO list, but finally I've mostly done X stuff...
I worked on updating xenocara's libGL and found two small bugfixes in the 7.11 branch that I backported to please our hobbits, so they could now upgrade clutter and import gnome-shell.
Still in the libGL/mesa land I worked on the infrastructure to build Gallium3D drivers. For the moment only the software drivers softpipe and llvmpipe can be built and there are still some minor issues but the performance looks promising for replacing the actual mesa software rasterizer on machines with unsupported graphic cards.
Paul Irofti(pirofti@) frolicked in hardwareland:
My main goal at g2k12 was continuing my work on porting OpenBSD to IA-64. I've fixed a few remaining compile issues, brought my work up to speed with current MI changes and had a shiny new kernel.
The problems started once I tried to boot with my new kernel. Having no Itanium present at the hackathon, Mike Larkin (mlarkin@) offered some of his binaries for the ski emulator. Starting with what he gave me I created multiple scenarios with the binaries offered by FreeBSD and the ones by Mike and I tried to trick the emulator into loading my kernel.
I don't know if the problem was the emulator, which kept crashing randomly, or the way I've setup the entry point and the locore bits. After a few days of work I decided to postpone this to work on at home.
In the meantime I've been juggling a few other projects. One of them was the ACPI subsystem. Robert Nagy (robert@) was 'kind' enough to push a monster laptop down my throat. This Asus-x52f would panic in every corner of the ACPI layer. It started by panicing on boot inside acpivideo(4) all the way to poweroff when it would enter an (almost) infinite loop inside it's own AML methods. I've poked at it for a while and made a few adjustments making sure that at least other people can boot similar machines.
This whole thing triggered a different topic in the ACPI/AML subsystem: locking. It was clear that there we needed to allow the SMI, the SCI and/or other sneaky parts of the BIOS to do their work while the ACPI layer spinlocks.
For example, there are machines with fake ECs that are really slow due to that and that might not finish their work by the time we get back into the OS. Thus leaving the OS with incomplete data and screwing up the AML flow. The proper way to do this is in three steps:
- make the ACPI drivers aware of the global acpi lock (_GLK)
- make the acpi(4) layer spinlock properly if needed
- force spinlocking no matter what at the AML layer
Thanks to Robert, Theo, the Foundation and your continuous donations, this was a really productive week where I got to bounce ideas and learn a lot from other developers while clearing my thoughts and ideas for my own OpenBSD projects.
Sir Mike the Brave(mikeb@) spins a cautionary tale of DMA ring carelessness:
I was excited to take some time and try to catch up a bit on 10Gb ethernet hardware support. This time I was porting a FreeBSD driver for the Emulex OneConnect CNA which in my case is a rebranded ServerEngines BladeEngine 3. I was able to complete the port, but unfortunately, while trying to fix an RX interrupt problem, I passed the card an incorrect pointer for the DMA opertaion and my remote box has frozen.
For the rest of the hackathon I had to do something else and figured I'd help Lawrence Teo (lteo@) to get his ipsecctl fix in. He has started off trying to make ipsecctl recognise an SA lifetime parameter and pass it on to the isakmpd but ended up rewriting the format of the configuration statements fed to the isakmpd because otherwise it was impossible to pass the lifetime value.
Christian Weisgerber(naddy@) polished some random turds:
For this hackathon, I didn't have any big project to tackle, so worked through a list of individually small changes. Some of these fell under the common theme of eliminating unsafe cryptography practices, in particular the use of the MD5 hash algorithm. I bugged schwarze@ to switch security(8) from MD5 to SHA-256, and added SHA-256 support to mtree(8). I also wanted to remove MD5 from the algorithms used to verify the integrity of distfiles in the ports tree. After some discussion we went further and dropped all the weaker hashes, since they neither added security in theory, nor had they been used in practice. Also, ipsecctl(8) now prevents some foot shooting by disallowing the AES-CTR/GCM/GMAC algorithms with manual keying because such setups cannot be used safely.
Simple string functions can be surprisingly hard. A configure test in a port reported the recently added stpncpy(3) function as broken and I found an off-by-one mistake there. Speaking of string functions, I also replaced all uses of stpcpy(3) in libintl from the gettext port, since the well-intentioned linker warnings about this function in the widely used library cluttered up our package build logs. There was the usual number of ports updates and fixes, too boring to list here, except maybe for the import of editors/nvi, which provides a version of the base system's vi(1) editor with added UTF-8 support and had been requested by Japanese, Romanian, and French members of our international developers community.
More reports came in than were possible to publish in this installment! Please stay tuned!
(Comments are closed)