* Re: ILP32 for ARM64: testing with glibc testsuite [not found] <1477081997-4770-1-git-send-email-ynorov@caviumnetworks.com> @ 2016-11-07 8:24 ` Yury Norov 2016-11-09 9:57 ` Yury Norov [not found] ` <20161028124659.GA24131@yury-N73SV> 1 sibling, 1 reply; 18+ messages in thread From: Yury Norov @ 2016-11-07 8:24 UTC (permalink / raw) To: arnd, catalin.marinas, linux-arm-kernel, linux-kernel, linux-doc, linux-arch, GNU C Library Cc: schwidefsky, heiko.carstens, pinskia, broonie, joseph, christoph.muellner, bamvor.zhangjian, szabolcs.nagy, klimov.linux, Nathan_Lynch, agraf, Prasun.Kapoor, kilobyte, geert, philipp.tomsich, manuel.montezelo, linyongting, maxim.kuvyrkov, davem, zhouchengming1, cmetcalf, Adhemerval Zanella, Steve Ellcey [-- Attachment #1: Type: text/plain, Size: 2684 bytes --] Hi all, [add libc-alpha mail list] For libc-alpha: this is the part of LKML submission with latest patches for aarch64/ilp32. https://www.spinics.net/lists/arm-kernel/msg537846.html Glibc that I use has also included consolidation patches from Adhemerval Zanella and me that are still not in the glibc master. The full series is: https://github.com/norov/glibc/tree/ilp32-2.24-dev2 Below is the results of glibc testsuite run for aarch64/lp64 in different configurations. Column names meaning: kvgv: kernel is vanilla, glibc is vanilla; kdgv: kernel has ilp32 patches applied, but ilp32 is disabled in config; glibc is vanilla; kegv: kernel has ilp32 patches applied and ilp32 is enabled, glibc is vanilla; kege: kernel patches are applied and enabled, glibc patches are applied. Only different lines are shown. Full results are in attached archive. I didn't analyze regressions deep yet, so any ideas/suggestions are appreciated. Yury. Test kvgv kdgv kegv kege conform/ISO/stdio.h/linknamespace PASS PASS PASS FAIL conform/ISO11/stdio.h/linknamespace PASS PASS PASS FAIL conform/ISO99/stdio.h/linknamespace PASS PASS PASS FAIL conform/POSIX/stdio.h/linknamespace PASS PASS PASS FAIL conform/POSIX/sys/stat.h/linknamespace PASS PASS PASS FAIL conform/UNIX98/stdio.h/linknamespace PASS PASS PASS FAIL conform/XOPEN2K/stdio.h/linknamespace PASS PASS PASS FAIL conform/XPG3/stdio.h/linknamespace PASS PASS PASS FAIL conform/XPG4/stdio.h/linknamespace PASS PASS PASS FAIL csu/tst-atomic PASS PASS PASS FAIL elf/check-localplt PASS PASS PASS FAIL iconvdata/mtrace-tst-loading PASS FAIL PASS PASS iconvdata/tst-loading PASS FAIL PASS PASS io/check-installed-headers-c PASS PASS PASS FAIL io/check-installed-headers-cxx PASS PASS PASS FAIL malloc/tst-malloc-backtrace FAIL PASS PASS PASS malloc/tst-malloc-thread-exit FAIL PASS PASS PASS malloc/tst-malloc-usable FAIL PASS PASS PASS malloc/tst-mallocfork FAIL PASS PASS PASS malloc/tst-mallocstate FAIL PASS PASS PASS malloc/tst-mallopt FAIL PASS PASS PASS malloc/tst-mcheck FAIL PASS PASS PASS malloc/tst-memalign FAIL PASS PASS PASS malloc/tst-obstack FAIL PASS PASS PASS malloc/tst-posix_memalign FAIL PASS PASS PASS malloc/tst-pvalloc FAIL PASS PASS PASS malloc/tst-realloc FAIL PASS PASS PASS malloc/tst-scratch_buffer FAIL PASS PASS PASS malloc/tst-trim1 FAIL PASS PASS PASS nptl/tst-eintr4 PASS PASS PASS NA posix/tst-regex2 PASS FAIL FAIL FAIL posix/tst-getaddrinfo4 PASS PASS FAIL FAIL posix/tst-getaddrinfo5 PASS PASS FAIL FAIL sysvipc/test-sysvmsg NA NA NA FAIL sysvipc/test-sysvsem NA NA NA FAIL sysvipc/test-sysvshm NA NA NA FAIL [-- Attachment #2: lp64.sum.tar.gz --] [-- Type: application/gzip, Size: 37007 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: ILP32 for ARM64: testing with glibc testsuite 2016-11-07 8:24 ` ILP32 for ARM64: testing with glibc testsuite Yury Norov @ 2016-11-09 9:57 ` Yury Norov 2016-11-16 11:26 ` Maxim Kuvyrkov [not found] ` <CC4F99A7-1FD2-486A-BD66-ED06F1B8BF50@linaro.org> 0 siblings, 2 replies; 18+ messages in thread From: Yury Norov @ 2016-11-09 9:57 UTC (permalink / raw) To: arnd, catalin.marinas, linux-arm-kernel, linux-kernel, linux-doc, linux-arch, GNU C Library Cc: schwidefsky, heiko.carstens, pinskia, broonie, joseph, christoph.muellner, bamvor.zhangjian, szabolcs.nagy, klimov.linux, Nathan_Lynch, agraf, Prasun.Kapoor, kilobyte, geert, philipp.tomsich, manuel.montezelo, linyongting, maxim.kuvyrkov, davem, zhouchengming1, cmetcalf, Adhemerval Zanella, Steve Ellcey On Mon, Nov 07, 2016 at 01:53:59PM +0530, Yury Norov wrote: > Hi all, > > [add libc-alpha mail list] > > For libc-alpha: this is the part of LKML submission with latest > patches for aarch64/ilp32. > https://www.spinics.net/lists/arm-kernel/msg537846.html > > Glibc that I use has also included consolidation patches from Adhemerval > Zanella and me that are still not in the glibc master. The full series is: > https://github.com/norov/glibc/tree/ilp32-2.24-dev2 > > Below is the results of glibc testsuite run for aarch64/lp64 > in different configurations. Column names meaning: > kvgv: kernel is vanilla, glibc is vanilla; > kdgv: kernel has ilp32 patches applied, but ilp32 is disabled in config; > glibc is vanilla; > kegv: kernel has ilp32 patches applied and ilp32 is enabled, glibc is vanilla; > kege: kernel patches are applied and enabled, glibc patches are applied. > > Only different lines are shown. Full results are in attached archive. The same, plus ILP32 regressions: Test kvgv kdgv kegv kege ilp32 conform/ISO/stdio.h/linknamespace PASS PASS PASS FAIL FAIL conform/ISO11/stdio.h/linknamespace PASS PASS PASS FAIL FAIL conform/ISO99/stdio.h/linknamespace PASS PASS PASS FAIL FAIL conform/POSIX/stdio.h/linknamespace PASS PASS PASS FAIL FAIL conform/POSIX/sys/stat.h/linknamespace PASS PASS PASS FAIL FAIL conform/UNIX98/stdio.h/linknamespace PASS PASS PASS FAIL FAIL conform/XOPEN2K/stdio.h/linknamespace PASS PASS PASS FAIL FAIL conform/XPG3/stdio.h/linknamespace PASS PASS PASS FAIL FAIL conform/XPG4/stdio.h/linknamespace PASS PASS PASS FAIL FAIL csu/tst-atomic PASS PASS PASS FAIL PASS elf/check-localplt PASS PASS PASS FAIL FAIL iconvdata/mtrace-tst-loading PASS FAIL PASS PASS FAIL iconvdata/tst-loading PASS FAIL PASS PASS PASS io/check-installed-headers-c PASS PASS PASS FAIL FAIL io/check-installed-headers-cxx PASS PASS PASS FAIL FAIL malloc/tst-malloc-backtrace FAIL PASS PASS PASS PASS malloc/tst-malloc-thread-exit FAIL PASS PASS PASS PASS malloc/tst-malloc-usable FAIL PASS PASS PASS PASS malloc/tst-mallocfork FAIL PASS PASS PASS PASS malloc/tst-mallocstate FAIL PASS PASS PASS PASS malloc/tst-mallopt FAIL PASS PASS PASS PASS malloc/tst-mcheck FAIL PASS PASS PASS PASS malloc/tst-memalign FAIL PASS PASS PASS PASS malloc/tst-obstack FAIL PASS PASS PASS PASS malloc/tst-posix_memalign FAIL PASS PASS PASS PASS malloc/tst-pvalloc FAIL PASS PASS PASS PASS malloc/tst-realloc FAIL PASS PASS PASS PASS malloc/tst-scratch_buffer FAIL PASS PASS PASS PASS malloc/tst-trim1 FAIL PASS PASS PASS PASS nptl/tst-eintr4 PASS PASS PASS NA NA posix/tst-regex2 PASS FAIL FAIL FAIL FAIL posix/tst-getaddrinfo4 PASS PASS FAIL FAIL PASS posix/tst-getaddrinfo5 PASS PASS FAIL FAIL PASS sysvipc/test-sysvmsg NA NA NA FAIL PASS sysvipc/test-sysvsem NA NA NA FAIL PASS sysvipc/test-sysvshm NA NA NA FAIL PASS c++-types-check PASS PASS PASS PASS FAIL debug/tst-backtrace4 PASS PASS PASS PASS FAIL elf/check-abi-libc PASS PASS PASS PASS FAIL elf/tst-tls1 PASS PASS PASS PASS FAIL elf/tst-tls1-static PASS PASS PASS PASS FAIL elf/tst-tls2 PASS PASS PASS PASS FAIL elf/tst-tls2-static PASS PASS PASS PASS FAIL elf/tst-tls3 PASS PASS PASS PASS FAIL math/check-abi-libm PASS PASS PASS PASS FAIL misc/tst-writev PASS PASS PASS PASS NA nptl/tst-cancel-self-canceltype PASS PASS PASS PASS FAIL nptl/tst-cancel1 PASS PASS PASS PASS FAIL nptl/tst-cancel10 PASS PASS PASS PASS FAIL nptl/tst-cancel11 PASS PASS PASS PASS FAIL nptl/tst-cancel13 PASS PASS PASS PASS FAIL nptl/tst-cancel15 PASS PASS PASS PASS FAIL nptl/tst-cancel16 PASS PASS PASS PASS FAIL nptl/tst-cancel17 PASS PASS PASS PASS FAIL nptl/tst-cancel18 PASS PASS PASS PASS FAIL nptl/tst-cancel2 PASS PASS PASS PASS FAIL nptl/tst-cancel20 PASS PASS PASS PASS FAIL nptl/tst-cancel21 PASS PASS PASS PASS FAIL nptl/tst-cancel24 PASS PASS PASS PASS FAIL nptl/tst-cancel25 PASS PASS PASS PASS FAIL nptl/tst-cancel26 PASS PASS PASS PASS FAIL nptl/tst-cancel27 PASS PASS PASS PASS FAIL nptl/tst-cancel3 PASS PASS PASS PASS FAIL nptl/tst-cancel4 PASS PASS PASS PASS FAIL nptl/tst-cancel5 PASS PASS PASS PASS FAIL nptl/tst-cancel6 PASS PASS PASS PASS FAIL nptl/tst-cancel7 PASS PASS PASS PASS FAIL nptl/tst-cancelx10 PASS PASS PASS PASS FAIL nptl/tst-cancelx11 PASS PASS PASS PASS FAIL nptl/tst-cancelx13 PASS PASS PASS PASS FAIL nptl/tst-cancelx15 PASS PASS PASS PASS FAIL nptl/tst-cancelx16 PASS PASS PASS PASS FAIL nptl/tst-cancelx17 PASS PASS PASS PASS FAIL nptl/tst-cancelx18 PASS PASS PASS PASS FAIL nptl/tst-cancelx2 PASS PASS PASS PASS FAIL nptl/tst-cancelx20 PASS PASS PASS PASS FAIL nptl/tst-cancelx21 PASS PASS PASS PASS FAIL nptl/tst-cancelx3 PASS PASS PASS PASS FAIL nptl/tst-cancelx4 PASS PASS PASS PASS FAIL nptl/tst-cancelx5 PASS PASS PASS PASS FAIL nptl/tst-cancelx6 PASS PASS PASS PASS FAIL nptl/tst-cancelx7 PASS PASS PASS PASS FAIL nptl/tst-cleanup4 PASS PASS PASS PASS FAIL nptl/tst-cleanupx4 PASS PASS PASS PASS FAIL nptl/tst-cond-except PASS PASS PASS PASS FAIL nptl/tst-cond7 PASS PASS PASS PASS FAIL nptl/tst-cond8 PASS PASS PASS PASS FAIL nptl/tst-fini1 PASS PASS PASS PASS FAIL nptl/tst-initializers1 PASS PASS PASS PASS FAIL nptl/tst-initializers1-c11 PASS PASS PASS PASS FAIL nptl/tst-initializers1-c89 PASS PASS PASS PASS FAIL nptl/tst-initializers1-c99 PASS PASS PASS PASS FAIL nptl/tst-initializers1-gnu11 PASS PASS PASS PASS FAIL nptl/tst-initializers1-gnu89 PASS PASS PASS PASS FAIL nptl/tst-initializers1-gnu99 PASS PASS PASS PASS FAIL nptl/tst-join5 PASS PASS PASS PASS FAIL nptl/tst-key3 PASS PASS PASS PASS FAIL nptl/tst-mutex8 PASS PASS PASS PASS FAIL nptl/tst-mutexpi8 PASS PASS PASS PASS FAIL nptl/tst-once3 PASS PASS PASS PASS FAIL nptl/tst-once4 PASS PASS PASS PASS FAIL nptl/tst-oncex3 PASS PASS PASS PASS FAIL nptl/tst-oncex4 PASS PASS PASS PASS FAIL nptl/tst-rwlock15 PASS PASS PASS PASS FAIL nptl/tst-rwlock8 PASS PASS PASS PASS FAIL nptl/tst-rwlock9 PASS PASS PASS PASS FAIL nptl/tst-sem11 PASS PASS PASS PASS FAIL nptl/tst-sem12 PASS PASS PASS PASS FAIL posix/bug-regex24 PASS PASS PASS PASS FAIL rt/tst-mqueue1 PASS PASS PASS PASS FAIL rt/tst-mqueue2 PASS PASS PASS PASS FAIL rt/tst-mqueue4 PASS PASS PASS PASS FAIL rt/tst-mqueue7 PASS PASS PASS PASS FAIL rt/tst-mqueue8 PASS PASS PASS PASS FAIL rt/tst-mqueue8x PASS PASS PASS PASS FAIL stdlib/tst-makecontext3 PASS PASS PASS PASS FAIL ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: ILP32 for ARM64: testing with glibc testsuite 2016-11-09 9:57 ` Yury Norov @ 2016-11-16 11:26 ` Maxim Kuvyrkov 2016-11-16 13:08 ` Yury Norov 2016-11-24 5:16 ` Yury Norov [not found] ` <CC4F99A7-1FD2-486A-BD66-ED06F1B8BF50@linaro.org> 1 sibling, 2 replies; 18+ messages in thread From: Maxim Kuvyrkov @ 2016-11-16 11:26 UTC (permalink / raw) To: Yury Norov; +Cc: GNU C Library [Resending with trimmed CC: to avoid libc-alpha's spam filter] > On Nov 9, 2016, at 1:56 PM, Yury Norov <ynorov@caviumnetworks.com> wrote: > > On Mon, Nov 07, 2016 at 01:53:59PM +0530, Yury Norov wrote: >> Hi all, >> >> [add libc-alpha mail list] >> >> For libc-alpha: this is the part of LKML submission with latest >> patches for aarch64/ilp32. >> https://www.spinics.net/lists/arm-kernel/msg537846.html >> >> Glibc that I use has also included consolidation patches from Adhemerval >> Zanella and me that are still not in the glibc master. The full series is: >> https://github.com/norov/glibc/tree/ilp32-2.24-dev2 >> >> Below is the results of glibc testsuite run for aarch64/lp64 >> in different configurations. Column names meaning: >> kvgv: kernel is vanilla, glibc is vanilla; >> kdgv: kernel has ilp32 patches applied, but ilp32 is disabled in config; >> glibc is vanilla; >> kegv: kernel has ilp32 patches applied and ilp32 is enabled, glibc is vanilla; >> kege: kernel patches are applied and enabled, glibc patches are applied. >> >> Only different lines are shown. Full results are in attached archive. Hi Yury, The general requirement merging ILP32 glibc patches is that LP64 does not regress in any reasonable configuration. This means that there should be 0 regressions between kvgv and kvge -- i.e., glibc in LP64 mode with and without ILP32 patches does not regress on the vanilla kernel. The kvge configuration is not in your testing matrix, and I suggest you make sure it has no regressions before fixing the more "advanced" configuration of kege. Ideally, there should be no regressions between kvgv and kege configurations, but I don't consider this to a requirement for glibc acceptance of ILP32 patches, since any regressions between kvge and kege configurations are likely to be on the kernel side. Speculating on the kernel requirements for ILP32 kernel patchset, I think there should be 0 regressions between kvgv and kdgv configurations, where you have only 3 tests to investigate and fix. [I do appreciate that there are progressions in your results as well, but the glibc policy is that they do not offset regressions.] The above only concerns LP64 support in kernel and glibc. Regarding ILP32 runtime, my opinion is that it is acceptable for ILP32 to have extra failures compared to LP64, since these are not regressions, but, rather, failures of a new configuration. From a superficial glance is seems that ILP32 linknamespace support requires attention, as well as stack unwinding (judging from NPTL failures). -- Maxim Kuvyrkov www.linaro.org > > The same, plus ILP32 regressions: > > Test kvgv kdgv kegv kege ilp32 > conform/ISO/stdio.h/linknamespace PASS PASS PASS FAIL FAIL > conform/ISO11/stdio.h/linknamespace PASS PASS PASS FAIL FAIL > conform/ISO99/stdio.h/linknamespace PASS PASS PASS FAIL FAIL > conform/POSIX/stdio.h/linknamespace PASS PASS PASS FAIL FAIL > conform/POSIX/sys/stat.h/linknamespace PASS PASS PASS FAIL FAIL > conform/UNIX98/stdio.h/linknamespace PASS PASS PASS FAIL FAIL > conform/XOPEN2K/stdio.h/linknamespace PASS PASS PASS FAIL FAIL > conform/XPG3/stdio.h/linknamespace PASS PASS PASS FAIL FAIL > conform/XPG4/stdio.h/linknamespace PASS PASS PASS FAIL FAIL > csu/tst-atomic PASS PASS PASS FAIL PASS > elf/check-localplt PASS PASS PASS FAIL FAIL > iconvdata/mtrace-tst-loading PASS FAIL PASS PASS FAIL > iconvdata/tst-loading PASS FAIL PASS PASS PASS > io/check-installed-headers-c PASS PASS PASS FAIL FAIL > io/check-installed-headers-cxx PASS PASS PASS FAIL FAIL > malloc/tst-malloc-backtrace FAIL PASS PASS PASS PASS > malloc/tst-malloc-thread-exit FAIL PASS PASS PASS PASS > malloc/tst-malloc-usable FAIL PASS PASS PASS PASS > malloc/tst-mallocfork FAIL PASS PASS PASS PASS > malloc/tst-mallocstate FAIL PASS PASS PASS PASS > malloc/tst-mallopt FAIL PASS PASS PASS PASS > malloc/tst-mcheck FAIL PASS PASS PASS PASS > malloc/tst-memalign FAIL PASS PASS PASS PASS > malloc/tst-obstack FAIL PASS PASS PASS PASS > malloc/tst-posix_memalign FAIL PASS PASS PASS PASS > malloc/tst-pvalloc FAIL PASS PASS PASS PASS > malloc/tst-realloc FAIL PASS PASS PASS PASS > malloc/tst-scratch_buffer FAIL PASS PASS PASS PASS > malloc/tst-trim1 FAIL PASS PASS PASS PASS > nptl/tst-eintr4 PASS PASS PASS NA NA > posix/tst-regex2 PASS FAIL FAIL FAIL FAIL > posix/tst-getaddrinfo4 PASS PASS FAIL FAIL PASS > posix/tst-getaddrinfo5 PASS PASS FAIL FAIL PASS > sysvipc/test-sysvmsg NA NA NA FAIL PASS > sysvipc/test-sysvsem NA NA NA FAIL PASS > sysvipc/test-sysvshm NA NA NA FAIL PASS > > c++-types-check PASS PASS PASS PASS FAIL > debug/tst-backtrace4 PASS PASS PASS PASS FAIL > elf/check-abi-libc PASS PASS PASS PASS FAIL > elf/tst-tls1 PASS PASS PASS PASS FAIL > elf/tst-tls1-static PASS PASS PASS PASS FAIL > elf/tst-tls2 PASS PASS PASS PASS FAIL > elf/tst-tls2-static PASS PASS PASS PASS FAIL > elf/tst-tls3 PASS PASS PASS PASS FAIL > math/check-abi-libm PASS PASS PASS PASS FAIL > misc/tst-writev PASS PASS PASS PASS NA > nptl/tst-cancel-self-canceltype PASS PASS PASS PASS FAIL > nptl/tst-cancel1 PASS PASS PASS PASS FAIL > nptl/tst-cancel10 PASS PASS PASS PASS FAIL > nptl/tst-cancel11 PASS PASS PASS PASS FAIL > nptl/tst-cancel13 PASS PASS PASS PASS FAIL > nptl/tst-cancel15 PASS PASS PASS PASS FAIL > nptl/tst-cancel16 PASS PASS PASS PASS FAIL > nptl/tst-cancel17 PASS PASS PASS PASS FAIL > nptl/tst-cancel18 PASS PASS PASS PASS FAIL > nptl/tst-cancel2 PASS PASS PASS PASS FAIL > nptl/tst-cancel20 PASS PASS PASS PASS FAIL > nptl/tst-cancel21 PASS PASS PASS PASS FAIL > nptl/tst-cancel24 PASS PASS PASS PASS FAIL > nptl/tst-cancel25 PASS PASS PASS PASS FAIL > nptl/tst-cancel26 PASS PASS PASS PASS FAIL > nptl/tst-cancel27 PASS PASS PASS PASS FAIL > nptl/tst-cancel3 PASS PASS PASS PASS FAIL > nptl/tst-cancel4 PASS PASS PASS PASS FAIL > nptl/tst-cancel5 PASS PASS PASS PASS FAIL > nptl/tst-cancel6 PASS PASS PASS PASS FAIL > nptl/tst-cancel7 PASS PASS PASS PASS FAIL > nptl/tst-cancelx10 PASS PASS PASS PASS FAIL > nptl/tst-cancelx11 PASS PASS PASS PASS FAIL > nptl/tst-cancelx13 PASS PASS PASS PASS FAIL > nptl/tst-cancelx15 PASS PASS PASS PASS FAIL > nptl/tst-cancelx16 PASS PASS PASS PASS FAIL > nptl/tst-cancelx17 PASS PASS PASS PASS FAIL > nptl/tst-cancelx18 PASS PASS PASS PASS FAIL > nptl/tst-cancelx2 PASS PASS PASS PASS FAIL > nptl/tst-cancelx20 PASS PASS PASS PASS FAIL > nptl/tst-cancelx21 PASS PASS PASS PASS FAIL > nptl/tst-cancelx3 PASS PASS PASS PASS FAIL > nptl/tst-cancelx4 PASS PASS PASS PASS FAIL > nptl/tst-cancelx5 PASS PASS PASS PASS FAIL > nptl/tst-cancelx6 PASS PASS PASS PASS FAIL > nptl/tst-cancelx7 PASS PASS PASS PASS FAIL > nptl/tst-cleanup4 PASS PASS PASS PASS FAIL > nptl/tst-cleanupx4 PASS PASS PASS PASS FAIL > nptl/tst-cond-except PASS PASS PASS PASS FAIL > nptl/tst-cond7 PASS PASS PASS PASS FAIL > nptl/tst-cond8 PASS PASS PASS PASS FAIL > nptl/tst-fini1 PASS PASS PASS PASS FAIL > nptl/tst-initializers1 PASS PASS PASS PASS FAIL > nptl/tst-initializers1-c11 PASS PASS PASS PASS FAIL > nptl/tst-initializers1-c89 PASS PASS PASS PASS FAIL > nptl/tst-initializers1-c99 PASS PASS PASS PASS FAIL > nptl/tst-initializers1-gnu11 PASS PASS PASS PASS FAIL > nptl/tst-initializers1-gnu89 PASS PASS PASS PASS FAIL > nptl/tst-initializers1-gnu99 PASS PASS PASS PASS FAIL > nptl/tst-join5 PASS PASS PASS PASS FAIL > nptl/tst-key3 PASS PASS PASS PASS FAIL > nptl/tst-mutex8 PASS PASS PASS PASS FAIL > nptl/tst-mutexpi8 PASS PASS PASS PASS FAIL > nptl/tst-once3 PASS PASS PASS PASS FAIL > nptl/tst-once4 PASS PASS PASS PASS FAIL > nptl/tst-oncex3 PASS PASS PASS PASS FAIL > nptl/tst-oncex4 PASS PASS PASS PASS FAIL > nptl/tst-rwlock15 PASS PASS PASS PASS FAIL > nptl/tst-rwlock8 PASS PASS PASS PASS FAIL > nptl/tst-rwlock9 PASS PASS PASS PASS FAIL > nptl/tst-sem11 PASS PASS PASS PASS FAIL > nptl/tst-sem12 PASS PASS PASS PASS FAIL > posix/bug-regex24 PASS PASS PASS PASS FAIL > rt/tst-mqueue1 PASS PASS PASS PASS FAIL > rt/tst-mqueue2 PASS PASS PASS PASS FAIL > rt/tst-mqueue4 PASS PASS PASS PASS FAIL > rt/tst-mqueue7 PASS PASS PASS PASS FAIL > rt/tst-mqueue8 PASS PASS PASS PASS FAIL > rt/tst-mqueue8x PASS PASS PASS PASS FAIL > stdlib/tst-makecontext3 PASS PASS PASS PASS FAIL ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: ILP32 for ARM64: testing with glibc testsuite 2016-11-16 11:26 ` Maxim Kuvyrkov @ 2016-11-16 13:08 ` Yury Norov 2016-11-24 5:16 ` Yury Norov 1 sibling, 0 replies; 18+ messages in thread From: Yury Norov @ 2016-11-16 13:08 UTC (permalink / raw) To: Maxim Kuvyrkov; +Cc: GNU C Library On Wed, Nov 16, 2016 at 03:25:40PM +0400, Maxim Kuvyrkov wrote: > [Resending with trimmed CC: to avoid libc-alpha's spam filter] > > > On Nov 9, 2016, at 1:56 PM, Yury Norov <ynorov@caviumnetworks.com> wrote: > > > > On Mon, Nov 07, 2016 at 01:53:59PM +0530, Yury Norov wrote: > >> Hi all, > >> > >> [add libc-alpha mail list] > >> > >> For libc-alpha: this is the part of LKML submission with latest > >> patches for aarch64/ilp32. > >> https://www.spinics.net/lists/arm-kernel/msg537846.html > >> > >> Glibc that I use has also included consolidation patches from Adhemerval > >> Zanella and me that are still not in the glibc master. The full series is: > >> https://github.com/norov/glibc/tree/ilp32-2.24-dev2 > >> > >> Below is the results of glibc testsuite run for aarch64/lp64 > >> in different configurations. Column names meaning: > >> kvgv: kernel is vanilla, glibc is vanilla; > >> kdgv: kernel has ilp32 patches applied, but ilp32 is disabled in config; > >> glibc is vanilla; > >> kegv: kernel has ilp32 patches applied and ilp32 is enabled, glibc is vanilla; > >> kege: kernel patches are applied and enabled, glibc patches are applied. > >> > >> Only different lines are shown. Full results are in attached archive. > > Hi Yury, Hi Maxim, thank you for response. > The general requirement merging ILP32 glibc patches is that LP64 does not > regress in any reasonable configuration. This means that there should be 0 > regressions between kvgv and kvge -- i.e., glibc in LP64 mode with and without > ILP32 patches does not regress on the vanilla kernel. The kvge configuration > is not in your testing matrix, and I suggest you make sure it has no regressions > before fixing the more "advanced" configuration of kege. Yes, I missed kvge as it's not so interesting from kernel point of view. But it's needed for glibc. I'll run that test and report soon. > Ideally, there should be no regressions between kvgv and kege configurations, > but I don't consider this to a requirement for glibc acceptance of ILP32 patches, > since any regressions between kvge and kege configurations are likely to be on > the kernel side. > > Speculating on the kernel requirements for ILP32 kernel patchset, I think there > should be 0 regressions between kvgv and kdgv configurations, where you have only > 3 tests to investigate and fix. > > [I do appreciate that there are progressions in your results as well, but the > glibc policy is that they do not offset regressions.] > > The above only concerns LP64 support in kernel and glibc. > > Regarding ILP32 runtime, my opinion is that it is acceptable for ILP32 to have > extra failures compared to LP64, since these are not regressions, but, rather, > failures of a new configuration. From a superficial glance is seems that ILP32 > linknamespace support requires attention, as well as stack unwinding (judging > from NPTL failures). Thanks again, it's clear, and I agree with your approach. Since there's less than 6 weeks till freeze, we'll focus on lp64 regressions, and after that on ilp32-specific ones. Yury. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: ILP32 for ARM64: testing with glibc testsuite 2016-11-16 11:26 ` Maxim Kuvyrkov 2016-11-16 13:08 ` Yury Norov @ 2016-11-24 5:16 ` Yury Norov 2016-11-24 7:36 ` Florian Weimer 2016-11-25 14:26 ` Ramana Radhakrishnan 1 sibling, 2 replies; 18+ messages in thread From: Yury Norov @ 2016-11-24 5:16 UTC (permalink / raw) To: Maxim Kuvyrkov; +Cc: GNU C Library On Wed, Nov 16, 2016 at 03:25:40PM +0400, Maxim Kuvyrkov wrote: > [Resending with trimmed CC: to avoid libc-alpha's spam filter] > > > On Nov 9, 2016, at 1:56 PM, Yury Norov <ynorov@caviumnetworks.com> wrote: > > > > On Mon, Nov 07, 2016 at 01:53:59PM +0530, Yury Norov wrote: > >> Hi all, > >> > >> [add libc-alpha mail list] > >> > >> For libc-alpha: this is the part of LKML submission with latest > >> patches for aarch64/ilp32. > >> https://www.spinics.net/lists/arm-kernel/msg537846.html > >> > >> Glibc that I use has also included consolidation patches from Adhemerval > >> Zanella and me that are still not in the glibc master. The full series is: > >> https://github.com/norov/glibc/tree/ilp32-2.24-dev2 > >> > >> Below is the results of glibc testsuite run for aarch64/lp64 > >> in different configurations. Column names meaning: > >> kvgv: kernel is vanilla, glibc is vanilla; > >> kdgv: kernel has ilp32 patches applied, but ilp32 is disabled in config; > >> glibc is vanilla; > >> kegv: kernel has ilp32 patches applied and ilp32 is enabled, glibc is vanilla; > >> kege: kernel patches are applied and enabled, glibc patches are applied. > >> > >> Only different lines are shown. Full results are in attached archive. > > Hi Yury, > > The general requirement merging ILP32 glibc patches is that LP64 does not regress in any reasonable configuration. This means that there should be 0 regressions between kvgv and kvge -- i.e., glibc in LP64 mode with and without ILP32 patches does not regress on the vanilla kernel. The kvge configuration is not in your testing matrix, and I suggest you make sure it has no regressions before fixing the more "advanced" configuration of kege. > > Ideally, there should be no regressions between kvgv and kege configurations, but I don't consider this to a requirement for glibc acceptance of ILP32 patches, since any regressions between kvge and kege configurations are likely to be on the kernel side. > > Speculating on the kernel requirements for ILP32 kernel patchset, I think there should be 0 regressions between kvgv and kdgv configurations, where you have only 3 tests to investigate and fix. > > [I do appreciate that there are progressions in your results as well, but the glibc policy is that they do not offset regressions.] > > The above only concerns LP64 support in kernel and glibc. > > Regarding ILP32 runtime, my opinion is that it is acceptable for ILP32 to have extra failures compared to LP64, since these are not regressions, but, rather, failures of a new configuration. From a superficial glance is seems that ILP32 linknamespace support requires attention, as well as stack unwinding (judging from NPTL failures). > > > -- > Maxim Kuvyrkov > www.linaro.org Hi Maxim, others, From last email we have fixed major part of fails, and also tested vanilla kernel with ilp32-enabled glibc, as Maxim asked (kvge column). Source trees: https://github.com/norov/glibc/tree/ilp32-2.24-dev5 https://github.com/norov/linux/tree/ilp32-4.9-rc4 Some fails analysis is below. ILP32 LP64 kvge Vanilla c++-types-check FAIL PASS PASS PASS conform/ISO/stdio.h/linknamespace FAIL FAIL FAIL PASS conform/ISO11/stdio.h/linknamespace FAIL FAIL FAIL PASS conform/ISO99/stdio.h/linknamespace FAIL FAIL FAIL PASS conform/POSIX/stdio.h/linknamespace FAIL FAIL FAIL PASS conform/POSIX/sys/stat.h/linknamespace FAIL FAIL FAIL PASS conform/UNIX98/stdio.h/linknamespace FAIL FAIL FAIL PASS conform/XOPEN2K/stdio.h/linknamespace FAIL FAIL FAIL PASS conform/XPG3/stdio.h/linknamespace FAIL FAIL FAIL PASS conform/XPG4/stdio.h/linknamespace FAIL FAIL FAIL PASS elf/check-localplt FAIL FAIL FAIL PASS elf/tst-tls1 FAIL PASS PASS PASS elf/tst-tls1-static FAIL PASS PASS PASS elf/tst-tls2 FAIL PASS PASS PASS elf/tst-tls2-static FAIL PASS PASS PASS elf/tst-tls3 FAIL PASS PASS PASS iconvdata/mtrace-tst-loading FAIL FAIL FAIL PASS iconvdata/tst-loading FAIL FAIL FAIL PASS io/check-installed-headers-c FAIL FAIL FAIL PASS io/check-installed-headers-cxx FAIL FAIL FAIL PASS localedata/mtrace-tst-leaks PASS FAIL FAIL PASS localedata/tst-leaks PASS FAIL FAIL PASS malloc/tst-malloc-backtrace PASS PASS PASS FAIL malloc/tst-malloc-thread-exit PASS PASS PASS FAIL malloc/tst-malloc-usable PASS PASS PASS FAIL malloc/tst-mallocfork PASS PASS PASS FAIL malloc/tst-mallocstate PASS PASS PASS FAIL malloc/tst-mallopt PASS PASS PASS FAIL malloc/tst-mcheck PASS PASS PASS FAIL malloc/tst-memalign PASS PASS PASS FAIL malloc/tst-obstack PASS PASS PASS FAIL malloc/tst-posix_memalign PASS PASS PASS FAIL malloc/tst-pvalloc PASS PASS PASS FAIL malloc/tst-realloc PASS PASS PASS FAIL malloc/tst-scratch_buffer PASS PASS PASS FAIL malloc/tst-trim1 PASS PASS PASS FAIL math/test-double PASS PASS PASS FAIL math/test-double-finite PASS PASS PASS FAIL math/test-idouble PASS PASS PASS FAIL misc/tst-writev NA NA NA PASS posix/tst-getaddrinfo4 PASS PASS FAIL PASS posix/tst-getaddrinfo5 PASS PASS FAIL PASS nptl/tst-cancel26 FAIL PASS PASS PASS nptl/tst-cancel27 FAIL PASS PASS PASS posix/tst-regex2 FAIL FAIL FAIL PASS rt/tst-mqueue1 FAIL PASS PASS PASS rt/tst-mqueue2 FAIL PASS PASS PASS rt/tst-mqueue4 FAIL PASS PASS PASS rt/tst-mqueue7 FAIL PASS PASS PASS stdlib/tst-makecontext3 FAIL PASS PASS PASS sunrpc/bug20790 PASS PASS NA NA sysvipc/test-sysvmsg PASS PASS NA NA sysvipc/test-sysvsem PASS PASS NA NA sysvipc/test-sysvshm PASS PASS NA NA Conform tests fail most probably because I have vanilla headers at standard paths (/usr/include). Modified headers are under different testing location. Steve also tested it, and he has modified headers at /usr/include, and he doesn't see failures of conform tests. I don't think that kernel or wrong ABI caused this regression. Most probably it's configuration issue. I also think that glibc should take headers from testing directory, not from standard paths. For me it's dangerous to replace standard headers with untested ones. Is there some option in glibc testsuite configuration to provide path to headers explicitly? elf/* tests fail only in ILP32 mode. We tracked it down to the linker problem that replaces accesses to TLS with direct address calculation if possible, and does it wrong for ilp32. This is definitely a linker problem, and ABI and kernel are not involved here. iconvdata/mtrace-tst-loading, iconvdata/tst-loading, io/check-installed-headers-c and io/check-installed-headers-cxx are most probably failing due to installed headers, like conform tests. localedata/mtrace-tst-leaks and localedata/tst-leaks fail only for me. Steve has it passed. I'm not sure but it also looks like configuration issue, or similar. posix/tst-getaddrinfo4 and posix/tst-getaddrinfo5 check broken URLs. We should investigate it, but I don't think it's ABI issue. Also, if I run them manually, they return 0, which means they are passed, I suppose. nptl/tst-cancel26, nptl/tst-cancel27, rt/tst-mqueue1,2,4,7 are also looking like the TLS issue. posix/tst-regex2 and stdlib/tst-makecontext3 fail only for me, so it's probably my local problem. So, with all regressions still been in the list, major part is looking like my local configuration problems. Others fail due to linker wrong behavior. I don't see any obvious failures caused by kernel or ABI errors. Yury. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: ILP32 for ARM64: testing with glibc testsuite 2016-11-24 5:16 ` Yury Norov @ 2016-11-24 7:36 ` Florian Weimer 2016-11-24 9:00 ` Yury Norov 2016-11-25 14:26 ` Ramana Radhakrishnan 1 sibling, 1 reply; 18+ messages in thread From: Florian Weimer @ 2016-11-24 7:36 UTC (permalink / raw) To: Yury Norov, Maxim Kuvyrkov; +Cc: GNU C Library On 11/24/2016 06:15 AM, Yury Norov wrote: > Conform tests fail most probably because I have vanilla headers at > standard paths (/usr/include). Modified headers are under different > testing location. Steve also tested it, and he has modified headers at > /usr/include, and he doesn't see failures of conform tests. I don't > think that kernel or wrong ABI caused this regression. Most probably > it's configuration issue. I also think that glibc should take headers > from testing directory, not from standard paths. For me it's dangerous > to replace standard headers with untested ones. Is there some option > in glibc testsuite configuration to provide path to headers explicitly? There is something peculiar with your test setup, I think. The conform tests do not do that for me. How do you configure, build, and test glibc? The instability in the malloc tests need investigation as well. If you run this on a simulator, you need to increase the test timeout. > elf/* tests fail only in ILP32 mode. We tracked it down to the linker > problem that replaces accesses to TLS with direct address calculation > if possible, and does it wrong for ilp32. This is definitely a linker > problem, and ABI and kernel are not involved here. The elf/check-localplt failure may have a different cause. What does the test report in the .out file? Thanks, Florian ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: ILP32 for ARM64: testing with glibc testsuite 2016-11-24 7:36 ` Florian Weimer @ 2016-11-24 9:00 ` Yury Norov 2016-11-24 9:06 ` Florian Weimer 0 siblings, 1 reply; 18+ messages in thread From: Yury Norov @ 2016-11-24 9:00 UTC (permalink / raw) To: Florian Weimer; +Cc: Maxim Kuvyrkov, GNU C Library On Thu, Nov 24, 2016 at 08:36:16AM +0100, Florian Weimer wrote: > On 11/24/2016 06:15 AM, Yury Norov wrote: > > >Conform tests fail most probably because I have vanilla headers at > >standard paths (/usr/include). Modified headers are under different > >testing location. Steve also tested it, and he has modified headers at > >/usr/include, and he doesn't see failures of conform tests. I don't > >think that kernel or wrong ABI caused this regression. Most probably > >it's configuration issue. I also think that glibc should take headers > >from testing directory, not from standard paths. For me it's dangerous > >to replace standard headers with untested ones. Is there some option > >in glibc testsuite configuration to provide path to headers explicitly? > > There is something peculiar with your test setup, I think. The conform > tests do not do that for me. How do you configure, build, and test glibc? This is my makefile to build it. https://github.com/norov/build-glibc If you have thoughts how to make it work right, I'll be really appreciated. > The instability in the malloc tests need investigation as well. If you run > this on a simulator, you need to increase the test timeout. I run it on qemu. It doesn't look like instability. malloc tests always fail on vanilla glibc, and always pass on patched one, for me. Andrew has it passed for vanilla glibc as well. > >elf/* tests fail only in ILP32 mode. We tracked it down to the linker > >problem that replaces accesses to TLS with direct address calculation > >if possible, and does it wrong for ilp32. This is definitely a linker > >problem, and ABI and kernel are not involved here. > > The elf/check-localplt failure may have a different cause. What does the > test report in the .out file? yury@yury-N73SV:~/work/glibc-img/lp64.build$ cat ./elf/check-localplt.out Extra PLT reference: libc.so: renameat Seems yes, it doesn't look like a TLS problem. I'll check it. Yury. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: ILP32 for ARM64: testing with glibc testsuite 2016-11-24 9:00 ` Yury Norov @ 2016-11-24 9:06 ` Florian Weimer 2016-11-24 9:10 ` Andrew Pinski 0 siblings, 1 reply; 18+ messages in thread From: Florian Weimer @ 2016-11-24 9:06 UTC (permalink / raw) To: Yury Norov; +Cc: Maxim Kuvyrkov, GNU C Library On 11/24/2016 09:59 AM, Yury Norov wrote: > On Thu, Nov 24, 2016 at 08:36:16AM +0100, Florian Weimer wrote: >> On 11/24/2016 06:15 AM, Yury Norov wrote: >> >>> Conform tests fail most probably because I have vanilla headers at >>> standard paths (/usr/include). Modified headers are under different >>> testing location. Steve also tested it, and he has modified headers at >>> /usr/include, and he doesn't see failures of conform tests. I don't >>> think that kernel or wrong ABI caused this regression. Most probably >>> it's configuration issue. I also think that glibc should take headers >> >from testing directory, not from standard paths. For me it's dangerous >>> to replace standard headers with untested ones. Is there some option >>> in glibc testsuite configuration to provide path to headers explicitly? >> >> There is something peculiar with your test setup, I think. The conform >> tests do not do that for me. How do you configure, build, and test glibc? > > This is my makefile to build it. > https://github.com/norov/build-glibc > > If you have thoughts how to make it work right, I'll be really > appreciated. Are you cross-compiling? I did not expect that. I thought native development was possible on aarch64 now. >> The instability in the malloc tests need investigation as well. If you run >> this on a simulator, you need to increase the test timeout. > > I run it on qemu. It doesn't look like instability. malloc tests > always fail on vanilla glibc, and always pass on patched one, for me. Have you tried to increase test timeout? > Andrew has it passed for vanilla glibc as well. Does Andrew use QEMU as well? >>> elf/* tests fail only in ILP32 mode. We tracked it down to the linker >>> problem that replaces accesses to TLS with direct address calculation >>> if possible, and does it wrong for ilp32. This is definitely a linker >>> problem, and ABI and kernel are not involved here. >> >> The elf/check-localplt failure may have a different cause. What does the >> test report in the .out file? > > yury@yury-N73SV:~/work/glibc-img/lp64.build$ cat ./elf/check-localplt.out > Extra PLT reference: libc.so: renameat > > Seems yes, it doesn't look like a TLS problem. I'll check it. Thanks. Florian ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: ILP32 for ARM64: testing with glibc testsuite 2016-11-24 9:06 ` Florian Weimer @ 2016-11-24 9:10 ` Andrew Pinski 0 siblings, 0 replies; 18+ messages in thread From: Andrew Pinski @ 2016-11-24 9:10 UTC (permalink / raw) To: Florian Weimer; +Cc: Yury Norov, Maxim Kuvyrkov, GNU C Library On Thu, Nov 24, 2016 at 1:06 AM, Florian Weimer <fweimer@redhat.com> wrote: > On 11/24/2016 09:59 AM, Yury Norov wrote: >> >> On Thu, Nov 24, 2016 at 08:36:16AM +0100, Florian Weimer wrote: >>> >>> On 11/24/2016 06:15 AM, Yury Norov wrote: >>> >>>> Conform tests fail most probably because I have vanilla headers at >>>> standard paths (/usr/include). Modified headers are under different >>>> testing location. Steve also tested it, and he has modified headers at >>>> /usr/include, and he doesn't see failures of conform tests. I don't >>>> think that kernel or wrong ABI caused this regression. Most probably >>>> it's configuration issue. I also think that glibc should take headers >>> >>> >from testing directory, not from standard paths. For me it's dangerous >>>> >>>> to replace standard headers with untested ones. Is there some option >>>> in glibc testsuite configuration to provide path to headers explicitly? >>> >>> >>> There is something peculiar with your test setup, I think. The conform >>> tests do not do that for me. How do you configure, build, and test >>> glibc? >> >> >> This is my makefile to build it. >> https://github.com/norov/build-glibc >> >> If you have thoughts how to make it work right, I'll be really >> appreciated. > > > Are you cross-compiling? I did not expect that. I thought native > development was possible on aarch64 now. > >>> The instability in the malloc tests need investigation as well. If you >>> run >>> this on a simulator, you need to increase the test timeout. >> >> >> I run it on qemu. It doesn't look like instability. malloc tests >> always fail on vanilla glibc, and always pass on patched one, for me. > > > Have you tried to increase test timeout? > >> Andrew has it passed for vanilla glibc as well. > > > Does Andrew use QEMU as well? Mine was native on a ThunderX T88 machine with a vanilla linux 4.8rc3. Thanks, Andrew > >>>> elf/* tests fail only in ILP32 mode. We tracked it down to the linker >>>> problem that replaces accesses to TLS with direct address calculation >>>> if possible, and does it wrong for ilp32. This is definitely a linker >>>> problem, and ABI and kernel are not involved here. >>> >>> >>> The elf/check-localplt failure may have a different cause. What does the >>> test report in the .out file? >> >> >> yury@yury-N73SV:~/work/glibc-img/lp64.build$ cat ./elf/check-localplt.out >> Extra PLT reference: libc.so: renameat >> >> Seems yes, it doesn't look like a TLS problem. I'll check it. > > > Thanks. > > Florian > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: ILP32 for ARM64: testing with glibc testsuite 2016-11-24 5:16 ` Yury Norov 2016-11-24 7:36 ` Florian Weimer @ 2016-11-25 14:26 ` Ramana Radhakrishnan 2016-11-25 15:30 ` Yury Norov 1 sibling, 1 reply; 18+ messages in thread From: Ramana Radhakrishnan @ 2016-11-25 14:26 UTC (permalink / raw) To: Yury Norov; +Cc: Maxim Kuvyrkov, GNU C Library Yury, > > elf/* tests fail only in ILP32 mode. We tracked it down to the linker > problem that replaces accesses to TLS with direct address calculation > if possible, and does it wrong for ilp32. This is definitely a linker > problem, and ABI and kernel are not involved here. That's entirely possible. Is there a bug report in binutils about this ? Are you (or anyone else you know) looking at fixing the linker ? regards Ramana ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: ILP32 for ARM64: testing with glibc testsuite 2016-11-25 14:26 ` Ramana Radhakrishnan @ 2016-11-25 15:30 ` Yury Norov 0 siblings, 0 replies; 18+ messages in thread From: Yury Norov @ 2016-11-25 15:30 UTC (permalink / raw) To: Ramana Radhakrishnan; +Cc: Maxim Kuvyrkov, GNU C Library On Fri, Nov 25, 2016 at 02:25:47PM +0000, Ramana Radhakrishnan wrote: > Yury, > > > > > elf/* tests fail only in ILP32 mode. We tracked it down to the linker > > problem that replaces accesses to TLS with direct address calculation > > if possible, and does it wrong for ilp32. This is definitely a linker > > problem, and ABI and kernel are not involved here. > > That's entirely possible. Is there a bug report in binutils about this > ? Are you (or anyone else you know) looking at fixing the linker ? This is detailed bug report in bugzilla: https://sourceware.org/bugzilla/show_bug.cgi?id=20868 Yury ^ permalink raw reply [flat|nested] 18+ messages in thread
[parent not found: <CC4F99A7-1FD2-486A-BD66-ED06F1B8BF50@linaro.org>]
[parent not found: <1479419136.908.90.camel@caviumnetworks.com>]
* Re: ILP32 for ARM64: testing with glibc testsuite [not found] ` <1479419136.908.90.camel@caviumnetworks.com> @ 2016-12-05 10:02 ` Zhangjian (Bamvor) 2016-12-05 10:07 ` Andreas Schwab 0 siblings, 1 reply; 18+ messages in thread From: Zhangjian (Bamvor) @ 2016-12-05 10:02 UTC (permalink / raw) To: Steve Ellcey, Maxim Kuvyrkov, Yury Norov Cc: arnd, catalin.marinas, linux-arm-kernel, linux-kernel, linux-doc, linux-arch, GNU C Library, schwidefsky, heiko.carstens, Andrew Pinski, broonie, Joseph S. Myers, christoph.muellner, Szabolcs Nagy, klimov.linux, Nathan_Lynch, agraf, Prasun Kapoor, kilobyte, Geert Uytterhoeven, Dr. Philipp Tomsich, manuel.montezelo, linyongting, davem, zhouchengming1, cmetcalf, Adhemerval Zanella, Zhangjian (Bamvor), Ding Tianhong, Hanjun Guo, jijun (D), chenjianguo3, liupeifeng (A) Hi, Steve On 2016/11/18 5:45, Steve Ellcey wrote: > On Wed, 2016-11-16 at 15:22 +0400, Maxim Kuvyrkov wrote: >>> >>> On Nov 9, 2016, at 1:56 PM, Yury Norov <ynorov@caviumnetworks.com> >>> wrote: >>> >>>> >>>> Below is the results of glibc testsuite run for aarch64/lp64 > > I have been running the glibc testsuite as well. I have only run it on > an ILP32 enabled kernel. Using that kernel, top-of-tree glibc, and the > ILP32 glibc patches I have no LP64 regressions. There are 5 failures > in LP64 mode but I get them with vanilla top-of-tree glibc sources too. > They are: > nptl/eintr1 (I actually don't run this because it kills the 'make check') > debug/tst-backtrace5 > debug/tst-backtrace6 > nptl/tst-stack4 > nptl/tst-thread_local1 > > In ILP32 mode I get 33 failures, they include the above failures (minus > nptl/tst-thread_local1) plus: > > c++-types-check > conform/ISO11/inttypes.h/conform > conform/ISO11/stdint.h/conform > conform/ISO99/inttypes.h/conform > conform/ISO99/stdint.h/conform > conform/POSIX2008/inttypes.h/conform > conform/POSIX2008/stdint.h/conform > conform/XOPEN2K/inttypes.h/conform > conform/XOPEN2K/stdint.h/conform > conform/XOPEN2K8/inttypes.h/conform > conform/XOPEN2K8/stdint.h/conform > elf/tst-tls1 > elf/tst-tls1-static > elf/tst-tls2 > elf/tst-tls2-static > elf/tst-tls3 > math/check-abi-libm > math/test-double > math/test-double-finite > math/test-float > math/test-float-finite > misc/tst-sync_file_range > nptl/tst-cancel26 > nptl/tst-cancel27 > nptl/tst-sem3 > rt/tst-mqueue1 > rt/tst-mqueue2 > rt/tst-mqueue4 > rt/tst-mqueue7 > stdlib/tst-makecontext3 > > I am currently looking at these ILP32 regressions (starting with the > tls failures) to see if I can figure out what is happening with them. Is there some progresses on it? We could collabrate to fix those issues. Regards Bamvor > > Steve Ellcey > sellcey@caviumnetworks.com > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: ILP32 for ARM64: testing with glibc testsuite 2016-12-05 10:02 ` Zhangjian (Bamvor) @ 2016-12-05 10:07 ` Andreas Schwab 2016-12-05 10:26 ` Zhangjian (Bamvor) [not found] ` <1480966437.29811.23.camel@caviumnetworks.com> 0 siblings, 2 replies; 18+ messages in thread From: Andreas Schwab @ 2016-12-05 10:07 UTC (permalink / raw) To: Zhangjian (Bamvor) Cc: Steve Ellcey, Maxim Kuvyrkov, Yury Norov, arnd, catalin.marinas, linux-arm-kernel, linux-kernel, linux-doc, linux-arch, GNU C Library, schwidefsky, heiko.carstens, Andrew Pinski, broonie, Joseph S. Myers, christoph.muellner, Szabolcs Nagy, klimov.linux, Nathan_Lynch, agraf, Prasun Kapoor, kilobyte, Geert Uytterhoeven, Dr. Philipp Tomsich, manuel.montezelo, linyongting, davem, <zh On Dez 05 2016, "Zhangjian (Bamvor)" <bamvor.zhangjian@huawei.com> wrote: > Is there some progresses on it? We could collabrate to fix those issues. All the elf/nptl/rt fails should be fixed by the recent binutils fixes. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: ILP32 for ARM64: testing with glibc testsuite 2016-12-05 10:07 ` Andreas Schwab @ 2016-12-05 10:26 ` Zhangjian (Bamvor) 2016-12-06 5:29 ` Yury Norov [not found] ` <1480966437.29811.23.camel@caviumnetworks.com> 1 sibling, 1 reply; 18+ messages in thread From: Zhangjian (Bamvor) @ 2016-12-05 10:26 UTC (permalink / raw) To: Andreas Schwab Cc: Steve Ellcey, Maxim Kuvyrkov, Yury Norov, arnd, catalin.marinas, linux-arm-kernel, linux-kernel, linux-doc, linux-arch, GNU C Library, schwidefsky, heiko.carstens, Andrew Pinski, broonie, Joseph S. Myers, christoph.muellner, Szabolcs Nagy, klimov.linux, Nathan_Lynch, agraf, Prasun Kapoor, kilobyte, Geert Uytterhoeven, Dr. Philipp Tomsich, manuel.montezelo, linyongting, davem, Zhangjian (Bamvor) On 2016/12/5 18:07, Andreas Schwab wrote: > On Dez 05 2016, "Zhangjian (Bamvor)" <bamvor.zhangjian@huawei.com> wrote: > >> Is there some progresses on it? We could collabrate to fix those issues. > > All the elf/nptl/rt fails should be fixed by the recent binutils fixes. Cool. How about the conform and other failures? Regards Bamvor > > Andreas. > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: ILP32 for ARM64: testing with glibc testsuite 2016-12-05 10:26 ` Zhangjian (Bamvor) @ 2016-12-06 5:29 ` Yury Norov 0 siblings, 0 replies; 18+ messages in thread From: Yury Norov @ 2016-12-06 5:29 UTC (permalink / raw) To: Zhangjian (Bamvor) Cc: Andreas Schwab, Steve Ellcey, Maxim Kuvyrkov, arnd, catalin.marinas, linux-arm-kernel, linux-kernel, linux-doc, linux-arch, GNU C Library, schwidefsky, heiko.carstens, Andrew Pinski, broonie, Joseph S. Myers, christoph.muellner, Szabolcs Nagy, klimov.linux, Nathan_Lynch, agraf, Prasun Kapoor, kilobyte, Geert Uytterhoeven, Dr. Philipp Tomsich, manuel.montezelo, linyongting, davem On Mon, Dec 05, 2016 at 06:24:11PM +0800, Zhangjian (Bamvor) wrote: > > > On 2016/12/5 18:07, Andreas Schwab wrote: > >On Dez 05 2016, "Zhangjian (Bamvor)" <bamvor.zhangjian@huawei.com> wrote: > > > >>Is there some progresses on it? We could collabrate to fix those issues. > > > >All the elf/nptl/rt fails should be fixed by the recent binutils fixes. > Cool. How about the conform and other failures? I think conform is only my local problem. I use pretty non-standard environment for build and testing - cross-compilation + qemu. Steve builds and runs tests natively, and he doesn't see that regressions. Yury ^ permalink raw reply [flat|nested] 18+ messages in thread
[parent not found: <1480966437.29811.23.camel@caviumnetworks.com>]
* Re: ILP32 for ARM64: testing with glibc testsuite [not found] ` <1480966437.29811.23.camel@caviumnetworks.com> @ 2016-12-06 8:31 ` Andreas Schwab 0 siblings, 0 replies; 18+ messages in thread From: Andreas Schwab @ 2016-12-06 8:31 UTC (permalink / raw) To: Steve Ellcey Cc: Zhangjian (Bamvor), Maxim Kuvyrkov, Yury Norov, arnd, catalin.marinas, linux-arm-kernel, linux-kernel, linux-doc, linux-arch, GNU C Library, schwidefsky, heiko.carstens, Andrew Pinski, broonie, Joseph S. Myers, christoph.muellner, Szabolcs Nagy, klimov.linux, Nathan_Lynch, agraf, Prasun Kapoor, kilobyte, Geert Uytterhoeven, Dr. Philipp Tomsich, manuel.montezelo, linyongting, davem, zh On Dez 05 2016, Steve Ellcey <sellcey@caviumnetworks.com> wrote: > FAIL: nptl/tst-cancel26 > FAIL: nptl/tst-cancel27 > FAIL: rt/tst-mqueue1 > FAIL: rt/tst-mqueue2 > FAIL: rt/tst-mqueue4 > FAIL: rt/tst-mqueue7 I don't see these failures. Maybe you need to rebuild libgcc? https://build.opensuse.org/package/live_build_log/devel:ARM:AArch64:ILP32/glibc-testsuite/standard/aarch64_ilp32 Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." ^ permalink raw reply [flat|nested] 18+ messages in thread
[parent not found: <20161028124659.GA24131@yury-N73SV>]
[parent not found: <cdf5cdf2-43af-6d7f-9e0c-72675fb83224@huawei.com>]
[parent not found: <266952F2-53F5-4D5E-83F0-6C8203092F67@linaro.org>]
[parent not found: <120041af-f4e9-5b6f-36dc-7d3535a1f01c@huawei.com>]
* Re: ILP32 for ARM64 - testing with lmbench [not found] ` <120041af-f4e9-5b6f-36dc-7d3535a1f01c@huawei.com> @ 2016-12-05 10:23 ` Zhangjian (Bamvor) [not found] ` <20161205141312.GC14429@e104818-lin.cambridge.arm.com> 0 siblings, 1 reply; 18+ messages in thread From: Zhangjian (Bamvor) @ 2016-12-05 10:23 UTC (permalink / raw) To: Maxim Kuvyrkov Cc: Yury Norov, arnd, catalin.marinas, linux-arm-kernel, linux-kernel, linux-doc, linux-arch, schwidefsky, heiko.carstens, Andrew Pinski, broonie, Joseph S. Myers, christoph.muellner, Szabolcs Nagy, klimov.linux, Nathan_Lynch, agraf, Prasun Kapoor, kilobyte, Geert Uytterhoeven, Dr. Philipp Tomsich, manuel.montezelo, linyongting, David Miller, zhouchengming1, cmetcalf, sellcey, hanjun.guo, Ding Tianhong, Zhangjian (Bamvor), GNU C Library, matt.spencer Hi, Catalin, Guys Do you have suggestion of next move of upstreaming ILP32? There are already the test results of lmbench and specint. Do you they are ok or need more data to prove no regression? I have also noticed that there are ILP32 failures in glibc testsuite. Is it the only blocker for merge ILP32(in technology part)? We appreciate any feedback/suggestion and hope could collaborate to improve the upstream progress. (cc libc-alpha to get more input). Thanks Bamvor On 2016/11/17 15:48, Zhangjian (Bamvor) wrote: > Hi, Maxim > > On 2016/11/17 13:02, Maxim Kuvyrkov wrote: >> Hi Bamvor, >> >> I'm surprised that you see this much difference from ILP32 patches on SPEC CPU2006int at all. The SPEC CPU2006 benchmarks spend almost no time in the kernel syscalls. I can imagine memory, TLB, >> and cache handling in the kernel could affect CPU2006 benchmarks. Do ILP32 patches touch code in those areas? >> >> Other than that, it would be interesting to check what the variance is between the 3 iterations of benchmark runs. Could you check what relative standard deviation is between the 3 iterations -- >> (STDEV(RUN1, RUN2, RUN3) / RUNselected)? >> >> For reference, in my [non-ILP32] benchmarking I see 1.1% for 401.bzip2, 0.8% for 429.mcf, 0.2% for 456.hmmer, and 0.1% for 462.libquantum. > Here is my result: > ILP32_merged ILP32_unmerged > 401.bzip2 0.31% 0.26% > 429.mcf 1.61% 1.36% > 456.hmmer 1.37% 1.57% > 462.libquantum 0.29% 0.28% > > Regards > > Bamvor > >> >> -- >> Maxim Kuvyrkov >> www.linaro.org >> >> >> >>> On Nov 17, 2016, at 7:28 AM, Zhangjian (Bamvor) <bamvor.zhangjian@huawei.com> wrote: >>> >>> Hi, all >>> >>> I test specint of aarch64 LP64 when aarch32 el0 disable/enabled respectively >>> and compare with ILP32 unmerged kernel(4.8-rc6) in our arm64 board. I found >>> that difference(ILP32 disabled/ILP32 unmerged) is bigger when aarch32 el0 is >>> enabled, compare with aarch32 el0 disabled kernel. And bzip2, mcg, hmmer, >>> libquantum are the top four differences[1]. Note that bigger is better in >>> specint test. >>> >>> In order to make sure the above results, I retest these four testcases in >>> reportable way(reference the command in the end). The result[2] show that >>> libquantum decrease -2.09% after ILP32 enabled and aarch32 on. I think it is in >>> significant. >>> >>> The result of lmbench is not stable in my board. I plan to dig it later. >>> >>> [1] The following test result is tested through --size=ref --iterations=3. >>> 1.1 Test when aarch32_el0 is enabled. >>> ILP32 disabled base line >>> 400.perlbench 100.00% 100% >>> 401.bzip2 99.35% 100% >>> 403.gcc 100.26% 100% >>> 429.mcf 102.75% 100% >>> 445.gobmk 100.00% 100% >>> 456.hmmer 95.66% 100% >>> 458.sjeng 100.00% 100% >>> 462.libquantum 100.00% 100% >>> 471.omnetpp 100.59% 100% >>> 473.astar 99.66% 100% >>> 483.xalancbmk 99.10% 100% >>> >>> 1.2 Test when aarch32_el0 is disabled >>> ILP32 disabled base line >>> 400.perlbench 100.22% 100% >>> 401.bzip2 100.95% 100% >>> 403.gcc 100.20% 100% >>> 429.mcf 100.76% 100% >>> 445.gobmk 100.36% 100% >>> 456.hmmer 97.94% 100% >>> 458.sjeng 99.73% 100% >>> 462.libquantum 98.72% 100% >>> 471.omnetpp 100.86% 100% >>> 473.astar 99.15% 100% >>> 483.xalancbmk 100.08% 100% >>> >>> [2] The following test result is tested through: runspec --config=my.cfg --size=test,train,ref --noreportable --tune=base,peak --iterations=3 bzip2 mcf hmmer libquantum >>> 2.1 Test when aarch32_el0 is enabled. >>> ILP32_enabled base line >>> 401.bzip2 100.82% 100% >>> 429.mcf 100.18% 100% >>> 456.hmmer 99.64% 100% >>> 462.libquantum 97.91% 100% >>> >>> Regards >>> >>> Bamvor >>> >>> On 2016/10/28 20:46, Yury Norov wrote: >>>> [Add Steve Ellcey, thanks for testing on ThunderX] >>>> >>>> Lmbench-3.0-a9 testing is performed on ThunderX machine to check that >>>> ILP32 series does not add performance regressions for LP64. Test >>>> summary is in the table below. Our measurements doesn't show >>>> significant performance regression of LP64 if ILP32 code is merged, >>>> both enabled or disabled. >>>> >>>> ILP32 enabled ILP32 disabled Standard Kernel >>>> null syscall 0.1066 0.1121 0.1121 >>>> 95.09% 100.00% >>>> >>>> stat 1.3947 1.3814 1.3864 >>>> 100.60% 99.64% >>>> >>>> fstat 0.4459 0.4344 0.4524 >>>> 98.56% 96.02% >>>> >>>> open/close 4.0606 4.0411 4.0453 >>>> 100.38% 99.90% >>>> >>>> read 0.4819 0.5014 0.5014 >>>> 96.11% 100.00% >>>> >>>> Tested with linux 4.8 because 4.9-rc1 is not fixed yet for ThunderX. >>>> Other system details below. >>>> >>>> Yury. >>>> >>>> ubuntu@crb6:~$ uname -a >>>> Linux crb6 4.8.0+ #3 SMP Thu Oct 27 11:01:32 PDT 2016 aarch64 aarch64 aarch64 GNU/Linux >>>> >>>> ubuntu@crb6:~$ cat /proc/meminfo >>>> MemTotal: 132011948 kB >>>> MemFree: 131442672 kB >>>> MemAvailable: 130695764 kB >>>> Buffers: 15696 kB >>>> Cached: 88088 kB >>>> SwapCached: 0 kB >>>> Active: 82760 kB >>>> Inactive: 41336 kB >>>> Active(anon): 20880 kB >>>> Inactive(anon): 8576 kB >>>> Active(file): 61880 kB >>>> Inactive(file): 32760 kB >>>> Unevictable: 0 kB >>>> Mlocked: 0 kB >>>> SwapTotal: 128920572 kB >>>> SwapFree: 128920572 kB >>>> Dirty: 0 kB >>>> Writeback: 0 kB >>>> AnonPages: 20544 kB >>>> Mapped: 19780 kB >>>> Shmem: 9060 kB >>>> Slab: 78804 kB >>>> SReclaimable: 27372 kB >>>> SUnreclaim: 51432 kB >>>> KernelStack: 8336 kB >>>> PageTables: 820 kB >>>> NFS_Unstable: 0 kB >>>> Bounce: 0 kB >>>> WritebackTmp: 0 kB >>>> CommitLimit: 194926544 kB >>>> Committed_AS: 256324 kB >>>> VmallocTotal: 135290290112 kB >>>> VmallocUsed: 0 kB >>>> VmallocChunk: 0 kB >>>> AnonHugePages: 0 kB >>>> ShmemHugePages: 0 kB >>>> ShmemPmdMapped: 0 kB >>>> CmaTotal: 0 kB >>>> CmaFree: 0 kB >>>> HugePages_Total: 0 >>>> HugePages_Free: 0 >>>> HugePages_Rsvd: 0 >>>> HugePages_Surp: 0 >>>> Hugepagesize: 2048 kB >>>> >>>> ubuntu@crb6:~$ cat /proc/cpuinfo >>>> processor : 0 >>>> BogoMIPS : 200.00 >>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics >>>> CPU implementer : 0x43 >>>> CPU architecture: 8 >>>> CPU variant : 0x1 >>>> CPU part : 0x0a1 >>>> CPU revision : 0 >>>> >>>> processor : 1 >>>> BogoMIPS : 200.00 >>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics >>>> CPU implementer : 0x43 >>>> CPU architecture: 8 >>>> CPU variant : 0x1 >>>> CPU part : 0x0a1 >>>> CPU revision : 0 >>>> >>>> processor : 2 >>>> BogoMIPS : 200.00 >>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics >>>> CPU implementer : 0x43 >>>> CPU architecture: 8 >>>> CPU variant : 0x1 >>>> CPU part : 0x0a1 >>>> CPU revision : 0 >>>> >>>> processor : 3 >>>> BogoMIPS : 200.00 >>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics >>>> CPU implementer : 0x43 >>>> CPU architecture: 8 >>>> CPU variant : 0x1 >>>> CPU part : 0x0a1 >>>> CPU revision : 0 >>>> >>>> processor : 4 >>>> BogoMIPS : 200.00 >>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics >>>> CPU implementer : 0x43 >>>> CPU architecture: 8 >>>> CPU variant : 0x1 >>>> CPU part : 0x0a1 >>>> CPU revision : 0 >>>> >>>> processor : 5 >>>> BogoMIPS : 200.00 >>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics >>>> CPU implementer : 0x43 >>>> CPU architecture: 8 >>>> CPU variant : 0x1 >>>> CPU part : 0x0a1 >>>> CPU revision : 0 >>>> >>>> processor : 6 >>>> BogoMIPS : 200.00 >>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics >>>> CPU implementer : 0x43 >>>> CPU architecture: 8 >>>> CPU variant : 0x1 >>>> CPU part : 0x0a1 >>>> CPU revision : 0 >>>> >>>> processor : 7 >>>> BogoMIPS : 200.00 >>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics >>>> CPU implementer : 0x43 >>>> CPU architecture: 8 >>>> CPU variant : 0x1 >>>> CPU part : 0x0a1 >>>> CPU revision : 0 >>>> >>>> processor : 8 >>>> BogoMIPS : 200.00 >>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics >>>> CPU implementer : 0x43 >>>> CPU architecture: 8 >>>> CPU variant : 0x1 >>>> CPU part : 0x0a1 >>>> CPU revision : 0 >>>> >>>> processor : 9 >>>> BogoMIPS : 200.00 >>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics >>>> CPU implementer : 0x43 >>>> CPU architecture: 8 >>>> CPU variant : 0x1 >>>> CPU part : 0x0a1 >>>> CPU revision : 0 >>>> >>>> processor : 10 >>>> BogoMIPS : 200.00 >>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics >>>> CPU implementer : 0x43 >>>> CPU architecture: 8 >>>> CPU variant : 0x1 >>>> CPU part : 0x0a1 >>>> CPU revision : 0 >>>> >>>> processor : 11 >>>> BogoMIPS : 200.00 >>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics >>>> CPU implementer : 0x43 >>>> CPU architecture: 8 >>>> CPU variant : 0x1 >>>> CPU part : 0x0a1 >>>> CPU revision : 0 >>>> >>>> processor : 12 >>>> BogoMIPS : 200.00 >>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics >>>> CPU implementer : 0x43 >>>> CPU architecture: 8 >>>> CPU variant : 0x1 >>>> CPU part : 0x0a1 >>>> CPU revision : 0 >>>> >>>> processor : 13 >>>> BogoMIPS : 200.00 >>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics >>>> CPU implementer : 0x43 >>>> CPU architecture: 8 >>>> CPU variant : 0x1 >>>> CPU part : 0x0a1 >>>> CPU revision : 0 >>>> >>>> processor : 14 >>>> BogoMIPS : 200.00 >>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics >>>> CPU implementer : 0x43 >>>> CPU architecture: 8 >>>> CPU variant : 0x1 >>>> CPU part : 0x0a1 >>>> CPU revision : 0 >>>> >>>> processor : 15 >>>> BogoMIPS : 200.00 >>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics >>>> CPU implementer : 0x43 >>>> CPU architecture: 8 >>>> CPU variant : 0x1 >>>> CPU part : 0x0a1 >>>> CPU revision : 0 >>>> >>>> processor : 16 >>>> BogoMIPS : 200.00 >>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics >>>> CPU implementer : 0x43 >>>> CPU architecture: 8 >>>> CPU variant : 0x1 >>>> CPU part : 0x0a1 >>>> CPU revision : 0 >>>> >>>> processor : 17 >>>> BogoMIPS : 200.00 >>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics >>>> CPU implementer : 0x43 >>>> CPU architecture: 8 >>>> CPU variant : 0x1 >>>> CPU part : 0x0a1 >>>> CPU revision : 0 >>>> >>>> processor : 18 >>>> BogoMIPS : 200.00 >>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics >>>> CPU implementer : 0x43 >>>> CPU architecture: 8 >>>> CPU variant : 0x1 >>>> CPU part : 0x0a1 >>>> CPU revision : 0 >>>> >>>> processor : 19 >>>> BogoMIPS : 200.00 >>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics >>>> CPU implementer : 0x43 >>>> CPU architecture: 8 >>>> CPU variant : 0x1 >>>> CPU part : 0x0a1 >>>> CPU revision : 0 >>>> >>>> processor : 20 >>>> BogoMIPS : 200.00 >>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics >>>> CPU implementer : 0x43 >>>> CPU architecture: 8 >>>> CPU variant : 0x1 >>>> CPU part : 0x0a1 >>>> CPU revision : 0 >>>> >>>> processor : 21 >>>> BogoMIPS : 200.00 >>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics >>>> CPU implementer : 0x43 >>>> CPU architecture: 8 >>>> CPU variant : 0x1 >>>> CPU part : 0x0a1 >>>> CPU revision : 0 >>>> >>>> processor : 22 >>>> BogoMIPS : 200.00 >>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics >>>> CPU implementer : 0x43 >>>> CPU architecture: 8 >>>> CPU variant : 0x1 >>>> CPU part : 0x0a1 >>>> CPU revision : 0 >>>> >>>> processor : 23 >>>> BogoMIPS : 200.00 >>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics >>>> CPU implementer : 0x43 >>>> CPU architecture: 8 >>>> CPU variant : 0x1 >>>> CPU part : 0x0a1 >>>> CPU revision : 0 >>>> >>>> processor : 24 >>>> BogoMIPS : 200.00 >>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics >>>> CPU implementer : 0x43 >>>> CPU architecture: 8 >>>> CPU variant : 0x1 >>>> CPU part : 0x0a1 >>>> CPU revision : 0 >>>> >>>> processor : 25 >>>> BogoMIPS : 200.00 >>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics >>>> CPU implementer : 0x43 >>>> CPU architecture: 8 >>>> CPU variant : 0x1 >>>> CPU part : 0x0a1 >>>> CPU revision : 0 >>>> >>>> processor : 26 >>>> BogoMIPS : 200.00 >>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics >>>> CPU implementer : 0x43 >>>> CPU architecture: 8 >>>> CPU variant : 0x1 >>>> CPU part : 0x0a1 >>>> CPU revision : 0 >>>> >>>> processor : 27 >>>> BogoMIPS : 200.00 >>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics >>>> CPU implementer : 0x43 >>>> CPU architecture: 8 >>>> CPU variant : 0x1 >>>> CPU part : 0x0a1 >>>> CPU revision : 0 >>>> >>>> processor : 28 >>>> BogoMIPS : 200.00 >>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics >>>> CPU implementer : 0x43 >>>> CPU architecture: 8 >>>> CPU variant : 0x1 >>>> CPU part : 0x0a1 >>>> CPU revision : 0 >>>> >>>> processor : 29 >>>> BogoMIPS : 200.00 >>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics >>>> CPU implementer : 0x43 >>>> CPU architecture: 8 >>>> CPU variant : 0x1 >>>> CPU part : 0x0a1 >>>> CPU revision : 0 >>>> >>>> processor : 30 >>>> BogoMIPS : 200.00 >>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics >>>> CPU implementer : 0x43 >>>> CPU architecture: 8 >>>> CPU variant : 0x1 >>>> CPU part : 0x0a1 >>>> CPU revision : 0 >>>> >>>> processor : 31 >>>> BogoMIPS : 200.00 >>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics >>>> CPU implementer : 0x43 >>>> CPU architecture: 8 >>>> CPU variant : 0x1 >>>> CPU part : 0x0a1 >>>> CPU revision : 0 >>>> >>>> processor : 32 >>>> BogoMIPS : 200.00 >>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics >>>> CPU implementer : 0x43 >>>> CPU architecture: 8 >>>> CPU variant : 0x1 >>>> CPU part : 0x0a1 >>>> CPU revision : 0 >>>> >>>> processor : 33 >>>> BogoMIPS : 200.00 >>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics >>>> CPU implementer : 0x43 >>>> CPU architecture: 8 >>>> CPU variant : 0x1 >>>> CPU part : 0x0a1 >>>> CPU revision : 0 >>>> >>>> processor : 34 >>>> BogoMIPS : 200.00 >>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics >>>> CPU implementer : 0x43 >>>> CPU architecture: 8 >>>> CPU variant : 0x1 >>>> CPU part : 0x0a1 >>>> CPU revision : 0 >>>> >>>> processor : 35 >>>> BogoMIPS : 200.00 >>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics >>>> CPU implementer : 0x43 >>>> CPU architecture: 8 >>>> CPU variant : 0x1 >>>> CPU part : 0x0a1 >>>> CPU revision : 0 >>>> >>>> processor : 36 >>>> BogoMIPS : 200.00 >>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics >>>> CPU implementer : 0x43 >>>> CPU architecture: 8 >>>> CPU variant : 0x1 >>>> CPU part : 0x0a1 >>>> CPU revision : 0 >>>> >>>> processor : 37 >>>> BogoMIPS : 200.00 >>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics >>>> CPU implementer : 0x43 >>>> CPU architecture: 8 >>>> CPU variant : 0x1 >>>> CPU part : 0x0a1 >>>> CPU revision : 0 >>>> >>>> processor : 38 >>>> BogoMIPS : 200.00 >>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics >>>> CPU implementer : 0x43 >>>> CPU architecture: 8 >>>> CPU variant : 0x1 >>>> CPU part : 0x0a1 >>>> CPU revision : 0 >>>> >>>> processor : 39 >>>> BogoMIPS : 200.00 >>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics >>>> CPU implementer : 0x43 >>>> CPU architecture: 8 >>>> CPU variant : 0x1 >>>> CPU part : 0x0a1 >>>> CPU revision : 0 >>>> >>>> processor : 40 >>>> BogoMIPS : 200.00 >>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics >>>> CPU implementer : 0x43 >>>> CPU architecture: 8 >>>> CPU variant : 0x1 >>>> CPU part : 0x0a1 >>>> CPU revision : 0 >>>> >>>> processor : 41 >>>> BogoMIPS : 200.00 >>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics >>>> CPU implementer : 0x43 >>>> CPU architecture: 8 >>>> CPU variant : 0x1 >>>> CPU part : 0x0a1 >>>> CPU revision : 0 >>>> >>>> processor : 42 >>>> BogoMIPS : 200.00 >>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics >>>> CPU implementer : 0x43 >>>> CPU architecture: 8 >>>> CPU variant : 0x1 >>>> CPU part : 0x0a1 >>>> CPU revision : 0 >>>> >>>> processor : 43 >>>> BogoMIPS : 200.00 >>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics >>>> CPU implementer : 0x43 >>>> CPU architecture: 8 >>>> CPU variant : 0x1 >>>> CPU part : 0x0a1 >>>> CPU revision : 0 >>>> >>>> processor : 44 >>>> BogoMIPS : 200.00 >>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics >>>> CPU implementer : 0x43 >>>> CPU architecture: 8 >>>> CPU variant : 0x1 >>>> CPU part : 0x0a1 >>>> CPU revision : 0 >>>> >>>> processor : 45 >>>> BogoMIPS : 200.00 >>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics >>>> CPU implementer : 0x43 >>>> CPU architecture: 8 >>>> CPU variant : 0x1 >>>> CPU part : 0x0a1 >>>> CPU revision : 0 >>>> >>>> processor : 46 >>>> BogoMIPS : 200.00 >>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics >>>> CPU implementer : 0x43 >>>> CPU architecture: 8 >>>> CPU variant : 0x1 >>>> CPU part : 0x0a1 >>>> CPU revision : 0 >>>> >>>> processor : 47 >>>> BogoMIPS : 200.00 >>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics >>>> CPU implementer : 0x43 >>>> CPU architecture: 8 >>>> CPU variant : 0x1 >>>> CPU part : 0x0a1 >>>> CPU revision : 0 >>>> >>> >> > ^ permalink raw reply [flat|nested] 18+ messages in thread
[parent not found: <20161205141312.GC14429@e104818-lin.cambridge.arm.com>]
* Re: ILP32 for ARM64 - testing with lmbench [not found] ` <20161205141312.GC14429@e104818-lin.cambridge.arm.com> @ 2016-12-11 12:08 ` Yury Norov 0 siblings, 0 replies; 18+ messages in thread From: Yury Norov @ 2016-12-11 12:08 UTC (permalink / raw) To: Catalin Marinas Cc: Zhangjian (Bamvor), Maxim Kuvyrkov, linux-doc, Szabolcs Nagy, heiko.carstens, cmetcalf, Dr. Philipp Tomsich, matt.spencer, Joseph S. Myers, linux-arch, zhouchengming1, sellcey, Prasun Kapoor, agraf, Geert Uytterhoeven, Ding Tianhong, kilobyte, manuel.montezelo, arnd, Andrew Pinski, linyongting, klimov.linux, broonie, linux-arm-kernel, GNU C Library, Nathan_Lynch, linux-kernel, hanjun.guo, schwidefsky, David Miller, christoph.muellner On Mon, Dec 05, 2016 at 02:13:12PM +0000, Catalin Marinas wrote: > On Mon, Dec 05, 2016 at 06:16:09PM +0800, Zhangjian (Bamvor) wrote: > > Do you have suggestion of next move of upstreaming ILP32? > > I mentioned the steps a few time before. I'm pasting them again here: > > 1. Complete the review of the Linux patches and ABI (no merge yet) > 2. Review the corresponding glibc patches (no merge yet) > 3. Ask (Linaro, Cavium) for toolchain + filesystem (pre-built and more > than just busybox) to be able to reproduce the testing in ARM > 4. More testing (LTP, trinity, performance regressions etc.) > 5. Move the ILP32 PCS out of beta (based on the results from 4) > 6. Check the market again to see if anyone still needs ILP32 > 7. Based on 6, decide whether to merge the kernel and glibc patches > > What's not explicitly mentioned in step 4 is glibc testing. Point 5 is > ARM's responsibility (toolchain folk). > > > There are already the test results of lmbench and specint. Do you they > > are ok or need more data to prove no regression? > > I would need to reproduce the tests myself, see step 3. Hi Catalin, > 3. Ask (Linaro, Cavium) for toolchain + filesystem (pre-built and more > than just busybox) to be able to reproduce the testing in ARM This is the Andrew's toolchain I use to build kernel, GLIBC, binutils etc: https://drive.google.com/open?id=0B93nHerV55yNVlVKaXpOOHQtbW8 It's not the latest build but it works well to me. This archive contains 4.9-rc8 kernel, initrd, sys-root, qemu image based on ilp32 busybox. https://drive.google.com/open?id=0B93nHerV55yNbVo0bko0bWlQeFE I can start linux on qemu and run basic commands and tests in ilp32 mode. This is my first attempt to create rootfs, and this is very basic busybox + sys-root. But it lets me start lp64 and ilp32 apps (find example there). If you need something more, let me know and I'll add it. You can also use any professional distro with this ilp32-enabled kernel, just copy sys-root there (like I actually do - I run Ubuntu 14 daily). BTW. This is of course good idea to build and test ilp32 user environment, but in real life I think ilp32 apps will work in lp64 userspace. > 4. More testing (LTP, trinity, performance regressions etc.) I also built and ran trinity. After ~24 hours I found all trinity threads stalled for lp64, and after another 24 hours I found it running but slower for ilp32. Kernel was alive in both cases. Yury. ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2016-12-11 12:08 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <1477081997-4770-1-git-send-email-ynorov@caviumnetworks.com>
2016-11-07 8:24 ` ILP32 for ARM64: testing with glibc testsuite Yury Norov
2016-11-09 9:57 ` Yury Norov
2016-11-16 11:26 ` Maxim Kuvyrkov
2016-11-16 13:08 ` Yury Norov
2016-11-24 5:16 ` Yury Norov
2016-11-24 7:36 ` Florian Weimer
2016-11-24 9:00 ` Yury Norov
2016-11-24 9:06 ` Florian Weimer
2016-11-24 9:10 ` Andrew Pinski
2016-11-25 14:26 ` Ramana Radhakrishnan
2016-11-25 15:30 ` Yury Norov
[not found] ` <CC4F99A7-1FD2-486A-BD66-ED06F1B8BF50@linaro.org>
[not found] ` <1479419136.908.90.camel@caviumnetworks.com>
2016-12-05 10:02 ` Zhangjian (Bamvor)
2016-12-05 10:07 ` Andreas Schwab
2016-12-05 10:26 ` Zhangjian (Bamvor)
2016-12-06 5:29 ` Yury Norov
[not found] ` <1480966437.29811.23.camel@caviumnetworks.com>
2016-12-06 8:31 ` Andreas Schwab
[not found] ` <20161028124659.GA24131@yury-N73SV>
[not found] ` <cdf5cdf2-43af-6d7f-9e0c-72675fb83224@huawei.com>
[not found] ` <266952F2-53F5-4D5E-83F0-6C8203092F67@linaro.org>
[not found] ` <120041af-f4e9-5b6f-36dc-7d3535a1f01c@huawei.com>
2016-12-05 10:23 ` ILP32 for ARM64 - testing with lmbench Zhangjian (Bamvor)
[not found] ` <20161205141312.GC14429@e104818-lin.cambridge.arm.com>
2016-12-11 12:08 ` Yury Norov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).