Re: Optimising poll(2)

Martin von Loewis (martin@mira.isdn.cs.tu-berlin.de)
Sat, 23 Aug 1997 14:39:50 +0200

> What I propose would change the way polling is done in the kernel,
> which of course involves a fair bit of work, but is hopefully worth
> it. The basic idea is to define a new field (called, say,
> "poll_events") inside the "struct file" structure which contains a
> poll event mask, just like what you get back from poll(). It would be
> the responsibility of each driver to add bits like POLLIN when data is
> available for reading and POLLOUT when data can be written without
> blocking, and of course all the other defined bits.

This sounds like a reasonable idea, and I like it much more than your
original poll2(2) proposal.

As you noticed, it might require a lot of changes. That could
be reduced if you add a flag to struct file that tells whether the
underlying driver supports synchronizing the field at all. Then you
could go through the files and see whether you can trust this field,
and call the poll operation otherwise.

With this interface, you could then implement that improved polling
for the most interesting case: TCP sockets. If you get a significant
speed-up on this, other driver authors could consider following your
interface.

Regards,
Martin