Messages in this thread | | | Subject | Re: Max tcp connections | Date | Fri, 12 Nov 1999 00:55:19 +0000 (GMT) | From | Alan Cox <> |
| |
> As for hitting performance issues under load, I don't believe this -- > unless Linux's poll implementation is very bad. Under load, poll will never
All poll implementations have this problem.
> block, so all it should require is a single linear traverse through the list > of file descriptors, tinkering with one byte each to indicate status. No > memory should need to be allocated, since it's all provided by the user. No > wait queues should need to be touched.
You have to touch all the wait queues in case you want to sleep. So it becomes 16384 iterations of sock->ops->poll() doing a wait queue add and then 16384 tear downs.
There has been experimental work doing caching of tables to avoid some overhead but for large scaling signal based I/O with rt signal returns is going to scale better as you pay one setup per handle not one setup per handle per event.
Alan
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |