fastpoll-readme

This patch removes most of the remaining time taken by select(2) and
poll(2), after patching to remove unnecessary wait queue manipulation
(see my poll and select patches). The remaining time is taken by calls
to the indirect f_op->poll function in struct file. These indirect
function calls take a lot of time. This patch provides the
infrastructure for individual drivers to support faster polling. Each
driver must be modified to take advantage of this new scheme. The
patch includes patches to the tty driver which now uses the new
polling scheme.

Timings on a Pentium 100 when polling descriptors 24-1023 with a zero
timeout are:

without this patch (2.1.53):
select:         2202 microseconds
poll:           2680 microseconds

with this patch:
select:         596 microseconds
poll:           807 microseconds

These timings are for a pseudo-terminal created for a rlogin session.

The way the new polling scheme works is through a new "poll_ctrl"
field for struct file. This should be initialised to NULL (standard
calls like get_empty_filp() do this implicitely when they call
memset() to clear the structure). The do_select() and do_poll()
functions look for this new field and if it is NULL, they revert to
the old behaviour (i.e. to try to call the f_op->poll indirect
function). If "poll_ctrl" is not NULL, then do_select() and do_poll()
will access poll_ctrl->events to obtain the current descriptor
status: no more indirect function call needed.

A driver must allocate space for a struct poll_control and call
poll_init_control() to initialise the structure. When a new file is
opened, you should call poll_add_file() which sets the "poll_ctrl"
field in the struct file and also adds the file to a list of files
associated with the struct poll_control.
Then, when the descriptor state changes, the driver must call
poll_notify() which will update the "events" field in struct
poll_control.

There are two ways that poll_notify() can be called. The best way is
for the driver to compute the poll events value and pass that to
poll_notify(). The lazy way is to instead pass POLLNVAL, which tell
poll_notify() to scan an associated list of files until it finds one
which has a valid f_op->poll indirect function.

When a file closes, the driver should call poll_remove_file(). When
the device-specific structure (like struct tty_struct for the tty
driver) is closed, you should call poll_free_control().

You may wonder why I didn't add a "poll_events" field directly to
struct file. The way it is now requires do_select() and do_poll() to
go through two pointer accesses: filp->poll_ctrl->events rather than
just one pointer access: filp->poll_events. The answer is that I did,
originally. The problem I found is that with the tty driver, in those
places where I needed to add the call to poll_notify(), there was no
access to the struct file pointer: the tty driver deals with
struct_tty structures, not file structures.
This patch deals with that by providing poll_add_file().

Note that this patch works on the assumption that a single
device-specific structure (i.e. struct tty_struct) may have several
open files associated with it, and that the poll event state is
specific to the device and can be shared between the files. If this is
not the case for your driver, you will need to create a poll_control
structure for each open file and call poll_init_control() followed by
poll_add_file() for each file. In other words, each struct
poll_control will only have one file associated with it.
If you strongly disagree with this assumption and the way of deal with
it, an alternative would be to add a "poll_events" field to the file
structure, and have do_select() and do_poll() look for that instead of
poll_ctrl->events. Then poll_notify() would update the "poll_events"
field for each associated file. Drivers which don't have a shared
device-specific structure would then modify the "poll_events" field
themselves, and dispose of dealing with the poll_control structure.
This change would be more optimal for said drivers, but would be less
optimal for (caring:-) sharing drivers like the tty driver, where
poll_notify() would be be unnecessarily iterating over the list of
files.
Anyway, if it becomes clear that the existing assumption is "Not
Good", then I'll bring out a newer version of this patch.

The latest patch is against 2.1.56. It is also compatible with my
pdeath patch.

ChangeLog:
  fastpoll.v1	Original, patches against 2.1.5[345]
  fastpoll.v2	Initialise events field to POLLNVAL and made calls to
		poll_notify() in the various serial drivers.
  fastpoll.v3	Updated for kernel 2.1.56