Re: Proposed new poll2() syscall

Richard Gooch (rgooch@atnf.CSIRO.AU)
Sat, 23 Aug 1997 11:28:35 +1000

Martin von Loewis writes:
> > This may be true if read(2) has to grab something off disc, but if
> > instead you are reading either from a file with the required bit in
> > the cache, or from a pipe/terminal/whatever then it should take far
> > less than a couple of milliseconds to read(2).
> > I timed the sample loop I sent in my last message: 2.3 milliseconds
> > for 10 000 iterations.
>
> Yes, but with each return of poll, at least one file descriptor is
> ready. For a typical server application, this descriptor will have
> between 20 and 4000 bytes of data ready (20 if it is a http request,
> otherwise a full data link layer packet).
>
> So for 10 000 iterations, you have to copy between 200 kB and 40 MB
> of data from kernel to user space, plus do the actual processing
> associated with those data. You cannot tell me you can do this
> in 2.3 milliseconds, or any amount of time in that order of magnitude.

If we assume it takes on average one minute for a user to read a
single http file, then the server will get a request (small packet)
every 6 milliseconds (10 000 connections). A 70 byte message takes 149
microseconds to read (Pentium 100). That message gets put on a
userland queue for later processing. The server reads all http
requests and places them on a queue. When it has scanned all fds for
activity, it then does non-blocking reads to attempt to service each
request in the queue. It takes 76 microseconds to read a 1024 bytes
from the cache and write them out. Note that there are not going to be
10 000 requests in the queue. It's more like 10 to 100. Most people
are still reading their page.
So, if the requested page is in the cache, it takes 146 microseconds
to process, ignoring the time spent in poll(2) and scanning the pollfd
list to see which descriptors are active. The latter takes 2.3
milliseconds. This is obviously time wasted, since the kernel has
already had to scan this list.
There is another problem in that poll(2) on 10 000 descriptors takes
48 milliseconds for a timeout of 0 (or 29 milliseconds with the patch
I sent last night). But I have some ideas on that too...

Regards,

Richard....