All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Vegard Nossum <vegard.nossum@gmail.com>
Cc: Oleg Nesterov <oleg@redhat.com>,
	Pekka Enberg <penberg@cs.helsinki.fi>,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH] signals: don't copy siginfo_t on dequeue
Date: Thu, 26 Feb 2009 19:50:53 +0100	[thread overview]
Message-ID: <20090226185053.GD31413@elte.hu> (raw)
In-Reply-To: <20090226184433.GA15644@damson.getinternet.no>


* Vegard Nossum <vegard.nossum@gmail.com> wrote:

> >From 60fc9a464377159ab807aec63277d4970019d631 Mon Sep 17 00:00:00 2001
> From: Vegard Nossum <vegard.nossum@gmail.com>
> Date: Thu, 26 Feb 2009 19:17:58 +0100
> Subject: [PATCH] signals: don't copy siginfo_t on dequeue
> 
> Instead of copying the siginfo_t whenever a signal is dequeued, just
> get the pointer to the struct sigqueue, which can be freed by the
> caller when the signal has been delivered.
> 
> We can save kernel text (x86, 32-bit):
> 
> $ scripts/bloat-o-meter vmlinux-unpatched vmlinux
> add/remove: 0/0 grow/shrink: 3/7 up/down: 81/-538 (-457)
> function                                     old     new   delta
> get_signal_to_deliver                        871     922     +51
> release_console_sem                          459     481     +22
> generate_resume_trace                        611     619      +8
> send_sigqueue                                257     253      -4
> vma_adjust                                  1101    1093      -8
> sys_rt_sigtimedwait                          548     531     -17
> dequeue_signal                               415     372     -43
> __dequeue_signal                             388     259    -129
> signalfd_read                               1290    1139    -151
> do_notify_resume                            2216    2030    -186
> 
> And we reduce stack pressure; In handle_signal() (in x86 code), we
> replace a siginfo_t (128 bytes) with a pointer (8 bytes on x86_64),
> and the same in signalfd_read().
> 
> There is a slight slowdown (2.02% relative increase in CPU time):
> 
> 		unpatched	patched
> ----------------------------------------
> mean:		3.078500	3.140800
> stddev:	0.074624	0.168989
> 
> (Numbers are: CPU time in seconds, for two processes to 
> ping-pong in total 655360 SIGUSR1/SIGUSR2 signals between each 
> other. This was repeated 100 times for each kernel.)

hm, does this SIGUSR1/SIGUSR2 test actually make use siginfo?

I.e. shouldnt we have seen a speedup, due to not having to copy 
the siginfo structure?

	Ingo

  reply	other threads:[~2009-02-26 18:51 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-26 18:44 [RFC][PATCH] signals: don't copy siginfo_t on dequeue Vegard Nossum
2009-02-26 18:50 ` Ingo Molnar [this message]
2009-02-26 19:10   ` Vegard Nossum
2009-02-26 20:19     ` Oleg Nesterov
2009-02-26 20:27       ` Ingo Molnar
2009-02-26 19:15 ` Oleg Nesterov
2009-02-26 20:18   ` Vegard Nossum
2009-02-26 20:36     ` Oleg Nesterov

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=20090226185053.GD31413@elte.hu \
    --to=mingo@elte.hu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=penberg@cs.helsinki.fi \
    --cc=vegard.nossum@gmail.com \
    /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.