> 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/