lkml.org 
[lkml]   [1999]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: > 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/

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:1.104 / U:0.304 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site