All of lore.kernel.org
 help / color / mirror / Atom feed
From: Davide Libenzi <davidel@xmailserver.org>
To: linux-kernel@vger.kernel.org
Subject: Collapsing RT signals ...
Date: Sun, 24 Jun 2001 18:03:12 -0700 (PDT)	[thread overview]
Message-ID: <XFMail.20010624180312.davidel@xmailserver.org> (raw)


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 the task_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_IN signals are queued with a single
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 failing read().
I'm just thinking at a way to optimize the signal delivery that is ( draft ) :


struct sigqueue {
        struct sigqueue *next;
        struct sigqueue **fsig;
        siginfo_t info;
};


struct fown_struct {
        int pid;                /* pid or -pgrp where SIGIO should be sent */
        uid_t uid, euid;        /* uid/euid of process setting the owner */
        int signum;             /* posix.1b rt signal to be delivered on IO */
        struct sigqueue *sig_hint;
};



At the end we'll have ( where fsig = &file->fown.sig_hint ) :


static int send_signal_hint(int sig, struct siginfo *info,
        struct sigpending *signals, struct sigqueue **fsig) {

        if (*fsig != NULL)
                merge_info(&(*fsig)->info, info);
        else {
                *fsig = allog_sig_queue();

                (*fsig)->fsig = fsig;

                copy_info(&(*fsig)->info, info);

                ...
                add-to-queue();
                ...
        }

        ...

}


When the message is delivered we'll have :

void clean_sig_hint(struct sigqueue *qsig) {

        if (qsig->fsig != NULL) {
                *(qsig->fsig) = NULL;
                qsig->fsig = NULL;
        }

}


When the file is closed :

void clean_fown_sighint(struct fown_struct *fown) {

        if (fown->sig_hint != NULL) {
                fown->sig_hint->fsig = NULL;
                fown->sig_hint = NULL;
        }

}


All these ops must be done under  sigmask_lock  lock ( send_signal() and signal
dequeue already does ).
This will make multiple signal from the same file to be stocked inside the same
slot reducing the RT signal traffic.

Comments ?






- Davide


             reply	other threads:[~2001-06-25  1:00 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-06-25  1:03 Davide Libenzi [this message]
  -- strict thread matches above, loose matches on Subject: below --
2001-06-25  4:21 Collapsing RT signals Dan Kegel
2001-06-25 15:30 ` Davide Libenzi
2001-06-25 15:43 ` Davide Libenzi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=XFMail.20010624180312.davidel@xmailserver.org \
    --to=davidel@xmailserver.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.