Collapsing RT signals ...
Quoted 5 lines · Davide Libenzi
I'm making some test with RT signals and looking at how they're implemented inside the kernel.
After having experienced frequent queue overflow signals I looked at how signals are queued inside thetask_struct.
There's no signals optimization inside and this make the queue length depending
Quoted 8 lines
on the request rate instead of the number of connections.
It can happen that two ( or more )POLL_INsignals are queued with a singleread()that sweep the buffer leaving other signals to issue reads ( read this as user-mode / kernel-mode switch ) that will fail due lack of data. So for every "superfluous" signal we'll have two user-mode / kernel-mode switches, one for signal delivery and one for a failingread(). I'm just thinking at a way to optimize the signal delivery that is ( draft ) :
...
I agree, the queue overflow case is a pain in the butt.
Before you get too far coding up your idea, have you read
http://marc.theaimsgroup.com/?l=linux-kernel&m=99023775430848&w=2
? He's already implemented and benchmarked a variation on this idea, maybe you could vet his code. He has taken it a step further than perhaps you were going to.
(See also http://www.kegel.com/c10k.html#nb.sigio )
- Dan
Quoted 18 lines · On 25-Jun-2001 Dan Kegel wrote:
Quoted 8 lines · Davide Libenzi
I'm making some test with RT signals and looking at how they're implemented inside the kernel.
After having experienced frequent queue overflow signals I looked at how signals are queued inside thetask_struct.
There's no signals optimization inside and this make the queue length depending
on the request rate instead of the number of connections.
It can happen that two ( or more )POLL_INsignals are queued with a singleQuoted 8 lines
read()that sweep the buffer leaving other signals to issue reads ( read this
as user-mode / kernel-mode switch ) that will fail due lack of data. So for every "superfluous" signal we'll have two user-mode / kernel-mode switches, one for signal delivery and one for a failingread(). I'm just thinking at a way to optimize the signal delivery that is ( draft ) :
...
Quoted 7 lines
I agree, the queue overflow case is a pain in the butt.
Before you get too far coding up your idea, have you read
http://marc.theaimsgroup.com/?l=linux-kernel&m=99023775430848&w=2
? He's already implemented and benchmarked a variation on this idea, maybe you could vet his code. He has taken it a step further than perhaps you were going to.
I'll do for sure, thank You.
Quoted 2 lines
(See also http://www.kegel.com/c10k.html#nb.sigio )
I already knew Your document, pretty cool.
- Davide
Quoted 18 lines · On 25-Jun-2001 Dan Kegel wrote:
Quoted 8 lines · Davide Libenzi
I'm making some test with RT signals and looking at how they're implemented inside the kernel.
After having experienced frequent queue overflow signals I looked at how signals are queued inside thetask_struct.
There's no signals optimization inside and this make the queue length depending
on the request rate instead of the number of connections.
It can happen that two ( or more )POLL_INsignals are queued with a singleQuoted 8 lines
read()that sweep the buffer leaving other signals to issue reads ( read this
as user-mode / kernel-mode switch ) that will fail due lack of data. So for every "superfluous" signal we'll have two user-mode / kernel-mode switches, one for signal delivery and one for a failingread(). I'm just thinking at a way to optimize the signal delivery that is ( draft ) :
...
Quoted 4 lines
I agree, the queue overflow case is a pain in the butt.
Before you get too far coding up your idea, have you read
http://marc.theaimsgroup.com/?l=linux-kernel&m=99023775430848&w=2
Double thank You Dan, they did exactly what I want to do :)
- Davide