Messages in this thread | | | Date | Wed, 15 Sep 1999 11:43:11 +0100 (GMT/BST) | From | Mike Jagdis <> | Subject | Re: > 15,000 Simultaneous Connections |
| |
On Wed, 15 Sep 1999, Stephen C. Tweedie wrote:
> The current code in the kernel delivers a normal, unqueued SIGIO > specifically to notify the application of overflow.
Personally I dislike that failure mode. The recovery method (using select or poll) involves allocating fairly significant chunks of kernel memory and spending significant time looping in kernel mode.
> >> And if you are delivering to a process group each process gets its > >> own siginfo allocated and queued. Then there's all the signal code > >> adding to the overhead on each event. > > There is no signal delivery involved at all. You just use sigwaitinfo() > to pull the next event off the queue. The signal should remain blocked > at all times if you are interested in performance.
The signal might not be delivered via a signal handler but there is overhead from the signal code. Each event causes a structure to be kmalloced and queued and each sigwaitinfo does an unqueue, copy to user space and kfree.
Mike
-- Failure isn't an option - it's built in to Windows .----------------------------------------------------------------------. | Mike Jagdis | Internet: mailto:mike@roan.co.uk | | Roan Technology Ltd. | | | 2 Markham Mews, Broad Street | Telephone: +44 118 989 0403 | | Wokingham ENGLAND | Fax: +44 118 989 1195 | `----------------------------------------------------------------------'
- 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/
| |