--1086566983-1423006827-937438980=:842
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Wed, 15 Sep 1999, Robert de Vries wrote:
> > In principle I approve, as long as it does not slow signal delivery. It
> > was obviously intended to work this way all along. Sorry I haven't time
> > to examine the code.
>
> This all depends on the speed of the slab allocator for the siginfo
> structure and the initialisation of the structure. I guess that it's fast
> because that was the reason for putting in the allocator in the first
> place and making a special slab for the siginfo structures.
Now doing a small benchmark reveals that RT signals take a little bit
longer to arrive than normal signals. I have written a small program to
measure this in a 2.2.5-22 redhat std. kernel.
This gives me for 1000 signals the following numbers on a 166 MHz Pentium:
normal signal takes on average 7.9 microsecs
RT signal takes on average 10.9 microsecs
The difference must be due to the queueing of the signal.
What does the community think?
Is the patch ok as is and is the 3 extra microsec a problem? (please run
the test prog on your platform to give me an idea what kind of latencies
you have on other archs/faster CPUs)
Or should I be more conservative in the patch and only put siginfo's in
the queue when they are either RT or if they pass siginfo in the first
place (all signals)?
Robert
-- Robert de Vries rhdv@rhdv.cistron.nl--1086566983-1423006827-937438980=:842 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="sigperf.c" Content-Transfer-Encoding: BASE64 Content-ID: <Pine.LNX.4.10.9909160143000.842@rhdv.cistron.nl> Content-Description: Content-Disposition: attachment; filename="sigperf.c"
I2luY2x1ZGUgPHN0ZGlvLmg+DQojaW5jbHVkZSA8c3RkbGliLmg+DQojaW5j bHVkZSA8c3lzL3RpbWUuaD4NCiNpbmNsdWRlIDx1bmlzdGQuaD4NCiNpbmNs dWRlIDxzaWduYWwuaD4NCg0KDQojaWYgMQ0KI2RlZmluZSBTSUdOTyBTSUdV U1IxCQkvKiBub3JtYWwgc2lnbmFsICovDQojZWxzZQ0KI2RlZmluZSBTSUdO TyBTSUdSVE1JTgkJLyogUlQgc2lnbmFsICovDQojZW5kaWYNCg0KI2RlZmlu ZSBOT0ZfREVMQVkgMTAwMA0KDQppbnQgZGVsYXlbMTAwMF07DQppbnQgaWRl bDsNCnN0cnVjdCB0aW1ldmFsIHN0YXJ0Ow0KDQp2b2lkIGhhbmRsZV9zaWdu YWwoaW50IHNpZ25hbCkNCnsNCiAgc3RydWN0IHRpbWV2YWwgZW5kOw0KICBp bnQgZGVsdGE7DQoNCiAgZ2V0dGltZW9mZGF5KCZlbmQsIE5VTEwpOw0KICBk ZWx0YSA9IChlbmQudHZfc2VjIC0gc3RhcnQudHZfc2VjKSAqIDEwMDAwMDAg Kw0KICAgIChlbmQudHZfdXNlYyAtIHN0YXJ0LnR2X3VzZWMpOw0KDQogIGRl bGF5W2lkZWwrK10gPSBkZWx0YTsNCn0NCg0Kdm9pZCBwcmludF9oaXN0KHZv aWQpDQp7DQojZGVmaW5lIEhJU1RTSVpFIDEwMDANCg0KICBpbnQgaGlzdFsx MDAwICsgMV07DQogIGludCBpOw0KDQogIG1lbXNldChoaXN0LCAwLCBzaXpl b2YoaGlzdCkpOw0KDQogIGZvciAoaSA9IDA7IGkgPCBOT0ZfREVMQVk7IGkr Kykgew0KICAgIGlmIChkZWxheVtpXSA+PSBISVNUU0laRSkgew0KICAgICAg cHJpbnRmKCJzYW1wbGUgJWQgb3ZlciBtYXggaGlzdDogJWRcbiIsIGksIGRl bGF5W2ldKTsNCiAgICAgIGhpc3RbSElTVFNJWkVdKys7DQogICAgfQ0KICAg IGVsc2Ugew0KICAgICAgaGlzdFtkZWxheVtpXV0rKzsNCiAgICB9DQogIH0N CiAgZm9yIChpID0gMDsgaSA8IEhJU1RTSVpFOyBpKyspIHsNCiAgICBpZiAo aGlzdFtpXSkgew0KICAgICAgcHJpbnRmKCIlZDogJWRcbiIsIGksIGhpc3Rb aV0pOw0KICAgIH0NCiAgfQ0KICBwcmludGYoIkhDOiAlZFxuIiwgaGlzdFtI SVNUU0laRV0pOw0KfQ0KDQp2b2lkIHByaW50X2F2Zyh2b2lkKQ0Kew0KICBk b3VibGUgc3VtOw0KICBpbnQgaTsNCg0KICBzdW0gPSAwOw0KICBmb3IgKGkg PSAwOyBpIDwgTk9GX0RFTEFZOyBpKyspIHsNCiAgICBzdW0gKz0gZGVsYXlb aV07DQogIH0NCg0KICBwcmludGYoImF2Zy4gZGVsYXk6ICVmXG4iLCBzdW0v Tk9GX0RFTEFZKTsNCn0NCg0KaW50IG1haW4odm9pZCkNCnsNCiAgc3RydWN0 IHNpZ2FjdGlvbiBhY3Q7DQogIGludCBpOw0KICBwaWRfdCBwOw0KDQogIHAg PSBnZXRwaWQoKTsNCg0KICBhY3Quc2FfZmxhZ3MgPSAwOw0KICBhY3Quc2Ff aGFuZGxlciA9IGhhbmRsZV9zaWduYWw7DQogIHNpZ2VtcHR5c2V0KCZhY3Qu c2FfbWFzayk7DQoNCiAgaWYgKHNpZ2FjdGlvbihTSUdOTywgJmFjdCwgTlVM TCkpIHsNCiAgICBwZXJyb3IoInNpZ2FjdGlvbiBmYWlsZWQiKTsNCiAgICBl eGl0KDEpOw0KICB9DQoNCiAgZm9yIChpID0gMDsgaSA8IE5PRl9ERUxBWTsg aSsrKSB7DQogICAgZ2V0dGltZW9mZGF5KCZzdGFydCwgTlVMTCk7DQogICAg a2lsbChwLCBTSUdOTyk7DQogIH0NCg0KICBwcmludF9oaXN0KCk7DQoNCiAg cHJpbnRfYXZnKCk7DQoNCiAgcmV0dXJuIDA7DQp9DQo= --1086566983-1423006827-937438980=:842--
- 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/