select timings

Jeff Roberson jroberson at chesapeake.net
Mon Jul 9 18:08:46 UTC 2007


On Mon, 9 Jul 2007, Peter Jeremy wrote:

> On 2007-Jul-08 20:46:40 -0400, Diane Bruce <db at db.net> wrote:
>> It is a rather naive test program, close all fd's except
>> for 0,1,2 of course, then open /dev/null multiple times, then do
>> a select() on each descriptor.  ~db/selt.c
>
> Thanks for the testing.  Can you please feed the output through (eg)
> src/tools/tools/ministat.
>
>> I will be trying some other select tests.
>> I suspect with a sparse fd_set, jeffr's results will be better than stock.
>> We'll see.
>
> Having a very large number of selected FDs return ready is unrealistic
> - I can't think of any real-world situation where this would occur.  A
> more realistic situation would look like a Poisson distribution with a
> small lambda (probably 1).  Writing a test suite for this is probably
> significantly more effort than your selt.c

Well this test is useful because it shows the expected worst case for this 
patch which is very encouraging since one version of it is not slower than 
the original select code.  That means in the best case we would expect my 
patch to be much faster.  For example, if there were 8k fds and only one 
triggered my patch only calls fo_poll() on one fd and simply frees the 
other descriptors.  Contrasted with the original code which calls poll all 
over again on each.

Thanks very much for your help Diane.

Jeff

>
> -- 
> Peter Jeremy
>


More information about the freebsd-arch mailing list