[lkml]   [1998]   [Apr]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: I/O completion ports for Linux
   Date: Wed, 1 Apr 1998 11:19:24 +1000
From: Richard Gooch <rgooch@atnf.CSIRO.AU>

The second patch removed the need for f_op->poll calls (an optional
flag was added to struct file which could be queried by do_select()
and do_poll()). This speeded up polling by another 3x to 4x. This
patch required no changes to userspace code.

Off hand, this sounds like a very good idea. Did you consider what
happens if there are two processes calling select on a shared file

Finally, the third patch created the poll2(2) syscall. This provided a
more efficient interface to the kernel, and removed the need for an
application to search all fds to see where there was activity. Since
the kernel already has to search all fds for activity, it is more
efficient to pass back to userspace a short list of fds which have
activity, saving the application the time of searching the big list of
fds. This new syscall works well for both single-threaded and
multi-threaded servers.

At some level, that's what the IO completion ports are all about,
although they add the additional twist that not only do they notify you
that data is available, but actually transfer the data to the memory
buffer and tell you how bytes were transfered. They also don't require
an additional system call (since you can use something like fcntl to
register the fd with the I/O completion port).

The question, then, is if we're going to be modifying the user API,
what ultimate API is best? A poll2 interface, or a I/O completion style

This is not to say that completion ports are not without their problems.
There are also questions of what happens if you try to register more
than one asyncronous I/O --- does it return an error, overwrite the
previous I/O request, etc? Do you allow asyncronous reads and writes?
Since I'm on the road, I still haven't had a chance to look at Robey's
proposal, but there are some design/API questions that we need to

Both the second and third patches would massively improve the
scalability of polling in Linux. Unfortunately, I didn't manage to
get either into Linus' kernel, so after perfecting my patches, I
stopped working on them. If I can get some encouragement from people
who's opinion has some weight with Linus, I could resurrect these

I believe the second patch is definitely worth revisiting and
considering for inclusion, modulo some design questions that I mentioned
above. The third patch IMO needs to wait on the higher-level
architectural question of how we want to provide this kind of
functionality in general....

- Ted

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to

 \ /
  Last update: 2005-03-22 13:42    [W:0.097 / U:9.636 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site