Re: [PATCH] /dev/epoll update ...

Davide Libenzi (davidel@xmailserver.org)
Thu, 20 Sep 2001 09:58:51 -0700 (PDT)


On 20-Sep-2001 Dan Kegel wrote:
> One more question: if I guess wrong initially about how many
> file descriptors I'll be monitoring with /dev/epoll, and I need
> to increase the size of the area inside /dev/epoll in the middle of
> my scan through the results, what is the proper sequence of calls?
>
> Some possibilities:
>
> 1) EP_ALLOC, and continue scanning through the results
>
> 2) EP_FREE, EP_ALLOC, EP_POLL because old results are now invalid
>
> 3) EP_FREE, EP_ALLOC, write new copies of all the old fds to /dev/epoll,
> EP_POLL, and start new scan
>
> I bet it's #3. Am I right?

I'm coding a solution that try to minimize the reallocation cost even if it's better
to preallocate the number of fds without changing it.
If you think to handle 200000 fds in your system the memory cost of the epoll
allocation is nothing compared to the file*, socket buffer, etc...

- Davide

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/