Messages in this thread | | | From | "David Schwartz" <> | Subject | RE: Max tcp connections | Date | Thu, 11 Nov 1999 17:18:57 -0800 |
| |
> > > > wait queues should need to be touched. > > > > > > You have to touch all the wait queues in case you want to sleep. > > > > Why? > > I have to ask each driver if it can complete a read/write/error if there > is a hup or other event outstanding. What you are suggesting means every > time there is an event I need to ask each device twice, once including a > queue once not including a queue. I have to have conditionals in > the drivers > and I slow down the normal path - which is waiting.
The normal path is waiting, but the path that matters under load is not waiting. Which is more important -- how little CPU you can use when you aren't under load or how much load you can take?
At least, as soon as the first fd shows that it's ready for I/O, take us off all the wait queues and stop putting us on them. But please stop blaming the poll API for an implementation problem that is _not_ inherent in the API.
> Signal based I/O is definitely the right approach for scaling
I still find this very hard to believe. How can one fast pass through poll (assuming a smarter implementation) be less efficient than the OS sending me 5,000 signals? That strikes me as an incredible claim.
A properly implemented poll is less than O(n) (assuming we don't block). The cost of the poll itself is O(n), but the higher the load, the fewer times we call poll because it takes us longer to get back to it and we find more active fds per poll.
A properly implemented signal based I/O will likely be O(n). If there are 10,000 connections each handing me one packet per second, I will need 10,000 signals per second. If the kernel is smart enough not to send me another signal for the same connection if I haven't already processed the previous one, isn't that likely to be >O(n) since each signal requires checking n pending signals.
DS
- 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/
| |