SEO

Barry,

On Thu, Oct 09, 2003 at 12:38:09PM +0100, Barry Scott wrote:
> You will need to benchmark to be sure that kqueue gives you an
> improvement.

You're absolutely correct. That's why I made that post. As with any
proposed change, a serious set of tests has to be made so that a more
conscious and right decision can be taken.

But the fact is, I currently don't have enough time to do such
performance tests. And in addition, I would like to see what other
people think/had experience with adapting software to use kqueue, as you
demonstrated in the post I'm replying to.

I will tell you why I decided to play a bit with kqueue. In a somewhat
rough set of considerations, the steps involved are fairly the same:

o Deconstructing the fd_sets;
o Checking each socket state;
o Reconstructing the fd_sets;

So what would differ using the function I posted would be step #2.
Taking a brief look at selscan() (in sys/kern/sys_generic.c), we can see
that the part responsible for marking a socket as ready (according to a
pre-determined state: ready for reading, ready for writing, etc), is:

if ((*fp->f_ops->fo_poll)(fp, flag[msk], p)) {
FD_SET(fd, pobits);
n++;
}

As we can see, it calls a polling function under the structure fp, which
describes the socket. As with kqueue, it seems to use a more obscure
framework of kqfilters spreaded all over the kernel, sys_pipe, tty,
uipc, vfs, and so on. At a first glance, so, the chance is that kqueue
may give us a more prompt and fast feedback about what is going on with
the descriptors we are polling for.

All too beautiful. All too theoretical. Still, it is undoubtable that
performance test analisys are needed and can show us clearly what
benefits (if any) such a change would bring us. So, once again, I ask
people to please test the file I've proposed and to send in feedback.

At the worst case, we can avoid an useless (but still tempting) change.

Cheers,
-p.