Linux-kernel mailing list archive 1999-37,: Re: [PATCH] 2.3.18: siginfo data available for all signals

# Re: [PATCH] 2.3.18: siginfo data available for all signals

Robert de Vries (rhdv@rhdv.cistron.nl)
Thu, 16 Sep 1999 01:43:00 +0200 (CEST)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: MBr: "6.20 hydra ide patch / DVD player/ Promise PDC20262 / Asus P2B bug"
- Previous message: Paul Jakma: "NFS problem: __nfs_fhget: inode still busy"

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to mime@docserver.cac.washington.edu for more info.

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

- Next message: MBr: "6.20 hydra ide patch / DVD player/ Promise PDC20262 / Asus P2B bug"
- Previous message: Paul Jakma: "NFS problem: __nfs_fhget: inode still busy"