[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <1353422297-29079-1-git-send-email-vgupta@synopsys.com>
Date: Tue, 20 Nov 2012 20:08:15 +0530
From: <Vineet.Gupta1@...opsys.com>
To: <arnd@...db.de>
CC: <linux-arch@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
Vineet Gupta <Vineet.Gupta1@...opsys.com>
Subject: [PATCH 0/2] RFC only - allow arches to over-ride unit sized user copies
From: Vineet Gupta <vgupta@...opsys.com>
Hi Arnd,
The current asm-generic/uaccess unit copy interface __{get,put}_user( )
defaults to using __copy_{to,from}_user( ). For archs which don't support
unaligned access, latter typically involves generated code for alignment
checks.
It is expected that arch will provide a fast path in __copy_{to,from}_user( )
for such unit sized copies - probably using __builtin_const_p( ) etc -
however the alignment checks still can't be eliminated altogether using that.
Even if they could, it woudl make the implementation messier IMHO.
However given that 2 separate interfaces already exist form beginning
(i.e. __get_user vs. __copy_from_user) will it make sense to allow arch to
provide alternate implementation of former w/o having to mess with latter.
I did a quick hack to that end and I can see that savings are more than
just "noise".
bloat-o-meter vmlinux_pre_uaccess vmlinux_uaccess_part1 | head
add/remove: 0/1 grow/shrink: 10/62 up/down: 1502/-7256 (-5754)
The patch which converts just __get_user follows. I've not
done the full/clean version yet as this is just to gather feedback.
Thx,
-Vineet
Vineet Gupta (2):
asm-generic: uaccess: allow arch to over-ride __get_user_fn()
ARC: provide optimal __get_user_fn()
arch/arc/include/asm/uaccess.h | 51 ++++++++++++++++++++++++++++++++++++++++
include/asm-generic/uaccess.h | 5 ++++
2 files changed, 56 insertions(+), 0 deletions(-)
--
1.7.4.1
--
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