thesjg edited this page Oct 6, 2010 · 13 revisions

This page contains content and code pertaining to the 2010 Google Summer of Code project for DragonFly BSD being undertaken by Samuel J. Greear.

To get some background on what the project is all about see the Proposal.

Stage 1 discusses some first steps taken in reimplementing select(2) on top of the kqueue subsystem. Stage 2 is the continuing saga of the select(2) reimplementation.

Stage 3 was brief and was all about Poll and Epoll

  • select(2) and poll(2) are extremely heavily used subsystems, it is very important that they operate correctly and with good performance. See libevent-2.0.5/regress to see the status of the regression tests included with libevent, which can be run against either kernel interface. See pipetest and dkftpbench for the results of micro-benchmarks that detail interface performance.

Stage 4 is about adding kqueue support to all of the kernel devices which lack it, but currently support the polling interface. see KQ Devices for the status of this work.

Stage 5 has been the removal of all polling interface code, including all usage of Selrecord/Selwakeup.

  • The bulk of the work was committed to the DragonFly BSD master branch around the 18 of July, 2010.

A number of Bugs have surfaced and had to be tracked down during this time.

Stage 6 has involved adding a single global token around the kqueue subsystem. This eliminates usage of critical sections and the giant lock. See Locking strategy – What still remains is to make yet another pass through all kqueue filter functions and determine if they are properly locking the subsystems they touch and fixing them or adding an acquisition of the mplock as necessary. For more information on the current state of MPSAFEty and future direction in this regard, see Locking strategy 2, pcpu.

Stage 7 was planned to involve determining if there is a waiting/listening thread or process for a listen socket on more than one or all cpu’s and making an effort to wake up the listener who will have the fastest access to the socket buffers. See Selective wakeup for more details.

Finally, the results of various application benchmarks: Apachebench