Contributed by rueda on from the In case of fire, open trace dept.
Martin Pieuchot (
mpi@) wrote in with a report from g2k19:
I was particularly excited to attend this year's general hackathon. I arrived without expectation. My goal was to have a fresh look at the kernel and discuss pending issues in a new way. Since I haven't really hacked on OpenBSD during the last year, I wasn't sure what to do next.
So I resumed hacking on a dtrace(1) or bpftrace(8) compatible tool to be able to answer the question. After some exchanges with many developers, I settled on a design and started writing code. Hackathons are to start projects, right? After a couple of days
tobhe@decided to join the effort and started working on a parser for the tool. Then a couple of days later, I had my answer:
This shows which codepaths are consuming CPU time in the kernel while building libc on a 2 CPU machine. It is now obvious which subsystem needs to be pushed away from the KERNEL_LOCK() in order to reduce contention during builds.
During the week many developers argued that the SCHED_LOCK() was too contended. I don't know which use case triggers such contention, but I gave a shot at splitting the lock. Sadly the change exposed a lock ordering problem, so it has been reverted. So today I enjoyed splitting the SCHED_LOCK() a bit further. I'm not sure if these changes are necessary for now. But I believe that it is more important to explain and show what is possible to do first.
That's also a reason why I spent so much time during the hackathon talking about the possible next steps to push the KERNEL_LOCK() down. I'm happy to see the number of developers working on parallelism grow. I also tried to explain the best I could the non-design of the NET_LOCK() and what could be do to improve parallelism in the Network Stack.
It was a really fun hackathon. I was really happy to see old and new faces. I am so thankful to all those clever people for sharing their time with me.
Thanks a lot to
mortimer@and the OpenBSD foundation for making that hackathon possible!
Thanks very much for the report Martin!
(Comments are closed)