| Message ID | cover.1591885760.git.afzal.mohd.ma@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | ARM: copy_{from,to}_user() for vmsplit 4g/4g | expand |
On Fri, 12 Jun 2020, afzal mohammed wrote: > Performance wise, results are not encouraging, 'dd' on tmpfs results, > > ARM Cortex-A8, BeagleBone White (256MiB RAM): > w/o series - ~29.5 MB/s > w/ series - ~20.5 MB/s > w/ series & highmem disabled - ~21.2 MB/s > > On Cortex-A15(2GiB RAM) in QEMU: > w/o series - ~4 MB/s > w/ series - ~2.6 MB/s > > Roughly a one-third drop in performance. Disabling highmem improves > performance only slightly. Could you compare with CONFIG_UACCESS_WITH_MEMCPY as well? Nicolas
Hi, On Fri, Jun 12, 2020 at 11:19:23AM -0400, Nicolas Pitre wrote: > On Fri, 12 Jun 2020, afzal mohammed wrote: > > Performance wise, results are not encouraging, 'dd' on tmpfs results, > Could you compare with CONFIG_UACCESS_WITH_MEMCPY as well? 512 1K 4K 16K 32K 64K 1M normal 30 46 89 95 90 85 65 uaccess_w_memcpy 28.5 45 85 92 91 85 65 w/ series 22 36 72 79 78 75 61 There are variations in the range +/-2 in some readings when repeated, not put above, to keep comparison simple. Regards afzal
Hi, On Fri, Jun 12, 2020 at 09:31:12PM +0530, afzal mohammed wrote: > 512 1K 4K 16K 32K 64K 1M > > normal 30 46 89 95 90 85 65 > > uaccess_w_memcpy 28.5 45 85 92 91 85 65 > > w/ series 22 36 72 79 78 75 61 For the sake of completeness all in MB/s, w/ various 'dd' 'bs' sizes. Regards afzal
Hi, copy_{from,to}_user() uaccess helpers are implemented by user page pinning, followed by temporary kernel mapping & then memcpy(). This helps to achieve user page copy when current virtual address mapping of the CPU excludes user pages. Other uaccess routines are also planned to be modified to make use of pinning plus kmap_atomic() based on the feedback here. This is done as one of the initial steps to achieve 4G virtual address mapping for user as well as Kernel on ARMv7 w/ LPAE. Motive behind this is to enable Kernel access till 4GiB (almost) as lowmem, thus helping in removing highmem support for platforms having upto 4GiB RAM. In the case of platforms having >4GiB, highmem is still required for the Kernel to be able to access whole RAM. Performance wise, results are not encouraging, 'dd' on tmpfs results, ARM Cortex-A8, BeagleBone White (256MiB RAM): w/o series - ~29.5 MB/s w/ series - ~20.5 MB/s w/ series & highmem disabled - ~21.2 MB/s On Cortex-A15(2GiB RAM) in QEMU: w/o series - ~4 MB/s w/ series - ~2.6 MB/s Roughly a one-third drop in performance. Disabling highmem improves performance only slightly. 'hackbench' also showed a similar pattern. Ways to improve the performance has to be explored, if any one has thoughts on it, please share. uaccess routines using page pinning & temporary kernel mapping is not something new, it has been done by Ingo long long ago [1] as part of 4G/4G user/kernel mapping implementation on x86, though not merged in mainline. Arnd has outlined basic design for vmsplit 4g/4g, uaccess routines using user page pinning plus kmap_atomic() is one part of that. [1] https://lore.kernel.org/lkml/Pine.LNX.4.44.0307082332450.17252-100000@localhost.localdomain/ Last 2 patches are only meant for testing first patch. Regards afzal afzal mohammed (3): lib: copy_{from,to}_user using gup & kmap_atomic() ARM: uaccess: let UACCESS_GUP_KMAP_MEMCPY enabling ARM: provide CONFIG_VMSPLIT_4G_DEV for development arch/arm/Kconfig | 9 ++ arch/arm/include/asm/uaccess.h | 20 ++++ arch/arm/kernel/armksyms.c | 2 + arch/arm/lib/Makefile | 7 +- lib/Kconfig | 4 + lib/Makefile | 3 + lib/uaccess_gup_kmap_memcpy.c | 162 +++++++++++++++++++++++++++++++++ 7 files changed, 205 insertions(+), 2 deletions(-) create mode 100644 lib/uaccess_gup_kmap_memcpy.c