[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <49507534.5080401@ct.jp.nec.com>
Date: Mon, 22 Dec 2008 21:20:52 -0800
From: Hiroshi Shimamoto <h-shimamoto@...jp.nec.com>
To: Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
"H. Peter Anvin" <hpa@...or.com>
Cc: linux-kernel@...r.kernel.org
Subject: [RFC -tip 0/4] x86: improve uaccess in signal
This patch series is experimental.
This is another proposal to improve uaccess in signal.
This patch series will improve signal handling performance. The normal path of
signal handling should be same as this;
http://lkml.org/lkml/2008/9/25/332
I think there is a lot of fixup code in signal generated by __{get|put}_user().
In most case kernel only needs to know whether there is error, and error value
is not important. And when an exception has occurred, kernel doesn't need to
continue following __{get|put}_user() in that function.
I think in fixup code to use direct jump to the tail of function and returns
error, will save fixup code size. This fixup code can be used __{get|put}_user()
calls in same function.
The concept code is;
int func()
{
int err = 0;
.section .fixup
error_out:
err = -EFAULT;
goto out;
.previous
__{get|put}_user(); /* fixup: jump to error_out */
__{get|put}_user();
__{get|put}_user();
:
out:
return err;
}
and the results are;
$ size *signal*.o.*
text data bss dec hex filename
4646 0 0 4646 1226 ia32_signal.o.new
6006 0 0 6006 1776 ia32_signal.o.old
3557 0 0 3557 de5 signal.o.new
4540 0 0 4540 11bc signal.o.old
3840 0 0 3840 f00 signal32.o.new
4876 0 0 4876 130c signal32.o.old
However, this code is tricky, I can't say compiler guarantees to keep the
order of this framework code and this code relies on the order, fixup section
is before the all __{get|put}_user() codes and the out label is just before
the return.
Comments are welcome.
Thanks,
Hiroshi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists