too many open file descriptors messages since bind 9.4.2-P1 (port dns94)

[Alfred Perlstein]

FWIW, the userland scan of the files is not nearly as bad as
what happens in the kernel when hundreds or thousands of objects
are accessed that blow out the cache, oh and the locking that
occurs as well.

* Peter Jeremy <peterjeremy at optushome.com.au> [080715 16:43] wrote:
> On 2008-Jul-15 16:09:17 -0700, Bakul Shah <bakul at bitblocks.com> wrote:
> >IIRC, when poll() returns n, you only look at the first n
> >values in the pollfd array so it is a win when you expect a
> >very small number of fds to be ready.  In the select case you
> >have to test the bit array until you see the last ready fd.
> 
> No.  Both poll(2) and select(2) return the number of FDs ready for
> I/O.  You need to scan the pollfd or fd_set array until you find that
> many FDs ready.
> 
> poll(2) is a win if you only need to test a small number of FDs
> compared to the number of FDs that the process has open.  In the case
> of bind, you have a large number of FDs to test, of which you are
> only expecting a very small number to be ready - if you don't
> treat fd_set as opaque, select(2) allows you to quickly skip large
> (roughly wordsize) chunks of un-interesting FDs.
> 
> Note that, based on sys_generic.c in 7.x and -CURRENT, poll(2) is
> limited to checking FD_SETSIZE descriptors, whilst select(2) has
> no upper limit.
> 
> -- 
> Peter Jeremy
> Please excuse any delays as the result of my ISP's inability to implement
> an MTA that is either RFC2821-compliant or matches their claimed behaviour.



-- 
- Alfred Perlstein