thesjg/gist:846711

## gistfile1.txt
Title: 	Coalesce + MPSAFE kevent, select, poll and wakeup
Student: 	Samuel Greear
Abstract: 	This project aims to apply DragonFly BSD design ideals to several related key kernel subsystems in an attempt to improve kernel performance, scalability and maintainability.
Content:

Name: Samuel J. Greear
Email: sjg@thesjg.com

Project title: Coalesce + MPSAFE kevent, select, poll and wakeup


Description of project goals, including details of how the delivered code will operate:

To refactor and/or reimplement two related facets of the kernel commonly used
by a myriad of userland programs into a form that conforms with DragonFly BSD
ideals. The select/poll/kevent subsystems, a common sleep path, as well as the
wakeup path will operate as near to as free of the giant kernel lock as possible
by the end of this project, ideally it will be possible to operate without it at
all. It is expected that this work can be completed for review and submission
by GSoC midterms. The remainder of the time will be spent exploring possible
optimizations.


Project timeline broken down by week,with details on each feature described in the project goals:

*** Community bonding Period ***

- Since I am involved with and have a possibly larger interest in the success of
the Google Summer of Code projects than my fellow students, find time to confer
with our project organizer. Determine methods by which I and my project can be
used to set a good example for other students to follow with their own projects.
- Get a head start on the research portion of the project

*** Week beginning May 24 ***
- Subsystem research
- Identify the best method of combining select, poll and kevent subsystems. This
is likely to be reimplementing select and poll as thin wrappers around kevent.
- Identify problematic (non-MPSAFE) subsystems utilized by kevent and friends
and how to address them.
- Identify preliminary synchronization/serialization strategies that will be
employed.
- Identify whether it would be possible to refactor or rewrite the kevent
subsystem to operate in a per-cpu fashion, this route seems optimal but may not
be possible.
- Begin work.

*** Weeks beginning May 31, June 7, 14, 21 ***
- Implement unified socket multiplexing subsystem code as per the decisions
made during week 1.
- Push back the giant lock where appropriate to make the entire subsystem
operate without obtaining it (directly, at the very least).
- Make adjustments and course corrections as necessary based on discussions
with my assigned mentor and the community.

*** Weeks beginning June 21, 28 [overlaps above] ***
- Implement generic unified and MPSAFE (pluggable?) wakeup paths.

*** Week beginning July 5 ***
- Rigorously test the overhauled subsystem under server workloads.
- Benchmark the original and overhauled subsystems to ensure that, at a minimum,
there were no performance regressions.
- Ensure all code is clean and well commented, ready for community review.
- Verify documentation is up-to-date.

*** July 12-16, Mid-term submission ***
- Ensure that I have supplied all code, patches, documentation and if necessary
a revised schedule with all previously agreed upon revisions by the 12'th so
that my mentor may complete my mid-term evaluation.
- Take advantage of midterms by having others review and test the cleaned up
and documented mid-term code.
- Commit any uncommitted code to DragonFly master branch after adequate testing.

*** Week beginning July 19 ***
- Implement several wakeup schemes, such as: one userland thread or process on
each cpu, all userland threads or processes, one userland thread or process on
the current cpu, one userland thread or process on some other cpu, etc.
- Benchmark these schemes under a variety of common server workloads, for
example, Apache configured with various configurations: worker, prefork, etc.

*** Week beginning July 26 ***
- If the previous weeks benchmarks show that implementing multiple wakeup
schemes would be beneficial, pare down to the most performant two or three
schemes.
- If continuing from July 19, investigate whether schemes can be reliably
selected using heuristics or whether a selection interface must be made
available to the process, implement this.
- If the results of work performed the previous week show that the complexity
of multiple wakeup schemes is unwarranted, spend this week locating and
beginning work on making a related subsystem MPSAFE.

*** Week beginning August 2 ***
- If continuing from July 19, spend this week performing optimizations and
validing benchmarks. Prepare documentation and benchmark results for public
consumption.
- If continuing from July 26, continue pushing back the Giant lock in related
subsystems.

*** Week beginning August 9 ***
    Wrap up any and all loose ends. Ask my mentor and others to review code
and benchmarks. Push any suitable bits to master.

*** August 16, firm "pencils down" ***
    Ensure that my assigned mentor has all useful materials produced available
for review.
	Title: Coalesce + MPSAFE kevent, select, poll and wakeup
	Student: Samuel Greear
	Abstract: This project aims to apply DragonFly BSD design ideals to several related key kernel subsystems in an attempt to improve kernel performance, scalability and maintainability.
	Content:

	Name: Samuel J. Greear
	Email: sjg@thesjg.com

	Project title: Coalesce + MPSAFE kevent, select, poll and wakeup



	Description of project goals, including details of how the delivered code will operate:

	To refactor and/or reimplement two related facets of the kernel commonly used
	by a myriad of userland programs into a form that conforms with DragonFly BSD
	ideals. The select/poll/kevent subsystems, a common sleep path, as well as the
	wakeup path will operate as near to as free of the giant kernel lock as possible
	by the end of this project, ideally it will be possible to operate without it at
	all. It is expected that this work can be completed for review and submission
	by GSoC midterms. The remainder of the time will be spent exploring possible
	optimizations.


	Project timeline broken down by week,with details on each feature described in the project goals:

	* Community bonding Period *

	- Since I am involved with and have a possibly larger interest in the success of
	the Google Summer of Code projects than my fellow students, find time to confer
	with our project organizer. Determine methods by which I and my project can be
	used to set a good example for other students to follow with their own projects.
	- Get a head start on the research portion of the project

	* Week beginning May 24 *
	- Subsystem research
	- Identify the best method of combining select, poll and kevent subsystems. This
	is likely to be reimplementing select and poll as thin wrappers around kevent.
	- Identify problematic (non-MPSAFE) subsystems utilized by kevent and friends
	and how to address them.
	- Identify preliminary synchronization/serialization strategies that will be
	employed.
	- Identify whether it would be possible to refactor or rewrite the kevent
	subsystem to operate in a per-cpu fashion, this route seems optimal but may not
	be possible.
	- Begin work.

	* Weeks beginning May 31, June 7, 14, 21 *
	- Implement unified socket multiplexing subsystem code as per the decisions
	made during week 1.
	- Push back the giant lock where appropriate to make the entire subsystem
	operate without obtaining it (directly, at the very least).
	- Make adjustments and course corrections as necessary based on discussions
	with my assigned mentor and the community.

	* Weeks beginning June 21, 28 [overlaps above] *
	- Implement generic unified and MPSAFE (pluggable?) wakeup paths.

	* Week beginning July 5 *
	- Rigorously test the overhauled subsystem under server workloads.
	- Benchmark the original and overhauled subsystems to ensure that, at a minimum,
	there were no performance regressions.
	- Ensure all code is clean and well commented, ready for community review.
	- Verify documentation is up-to-date.

	* July 12-16, Mid-term submission *
	- Ensure that I have supplied all code, patches, documentation and if necessary
	a revised schedule with all previously agreed upon revisions by the 12'th so
	that my mentor may complete my mid-term evaluation.
	- Take advantage of midterms by having others review and test the cleaned up
	and documented mid-term code.
	- Commit any uncommitted code to DragonFly master branch after adequate testing.

	* Week beginning July 19 *
	- Implement several wakeup schemes, such as: one userland thread or process on
	each cpu, all userland threads or processes, one userland thread or process on
	the current cpu, one userland thread or process on some other cpu, etc.
	- Benchmark these schemes under a variety of common server workloads, for
	example, Apache configured with various configurations: worker, prefork, etc.

	* Week beginning July 26 *
	- If the previous weeks benchmarks show that implementing multiple wakeup
	schemes would be beneficial, pare down to the most performant two or three
	schemes.
	- If continuing from July 19, investigate whether schemes can be reliably
	selected using heuristics or whether a selection interface must be made
	available to the process, implement this.
	- If the results of work performed the previous week show that the complexity
	of multiple wakeup schemes is unwarranted, spend this week locating and
	beginning work on making a related subsystem MPSAFE.

	* Week beginning August 2 *
	- If continuing from July 19, spend this week performing optimizations and
	validing benchmarks. Prepare documentation and benchmark results for public
	consumption.
	- If continuing from July 26, continue pushing back the Giant lock in related
	subsystems.

	* Week beginning August 9 *
	Wrap up any and all loose ends. Ask my mentor and others to review code
	and benchmarks. Push any suitable bits to master.

	* August 16, firm "pencils down" *
	Ensure that my assigned mentor has all useful materials produced available
	for review.