This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Ping: ILP32 on aarch64 patches
- From: Yury Norov <ynorov at caviumnetworks dot com>
- To: Ramana Radhakrishnan <ramana dot gcc at googlemail dot com>
- Cc: Szabolcs Nagy <nsz at port70 dot net>, Steve Ellcey <sellcey at caviumnetworks dot com>, libc-alpha <libc-alpha at sourceware dot org>, Carlos O'Donell <carlos at redhat dot com>, Catalin Marinas <catalin dot marinas at arm dot com>, Maxim Kuvyrkov <maxim dot kuvyrkov at linaro dot org>, Andrew Pinski <pinskia at gmail dot com>, Arnd Bergman <arnd at arndb dot de>, Bamvor Zhangjian <bamvor dot zhangjian at huawei dot com>, Marcus Shawcroft <Marcus dot Shawcroft at arm dot com>
- Date: Sat, 28 Jan 2017 19:23:03 +0530
- Subject: Re: Ping: ILP32 on aarch64 patches
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=none (sender IP is ) smtp.mailfrom=Yuri dot Norov at caviumnetworks dot com;
- References: <1482949070.2445.4.camel@caviumnetworks.com> <20161228220753.GC6695@port70.net> <20170101222006.GA9513@yury-N73SV> <CAJA7tRaceUaK-+v3F5nzBg54WZpv7EtZ-5y0PxtPK-auWhX-HQ@mail.gmail.com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
Hi Ramana,
On Fri, Jan 27, 2017 at 05:39:10PM +0000, Ramana Radhakrishnan wrote:
> >
> >> `4. More testing (LTP, trinity, performance regressions etc.)
> >
> > Performance, LTP, trinity and glibc testsuites are ran, and
> > some regressions found comparing to lp64, but nothing critical
> > there. For example, LTP shows ~5 extra fails, and most of them
> > are due to weird fail of mkfs tool, which is called in that
> > tests. Trinity is OK to me, and performance in lp64 is looking
> > the same - some tests little faster, some little slower, all in
> > 5% range.
>
>
> I don't grok enough about LTP to know if those extra failures are
> acceptable and will leave that to Catalin and other kernel folks to
> comment.
>
> This statement about performance variations with +/- 5% in lp64 is a
> bit too much of hand-wavium for me and begs a few questions :) Most
> teams fight to get performance improvements across the toolchain for
> aarch64, thus dropping overall performance is something in some
> situations worries me.
It doesn't mean that lp64 gets 5% slower, at all. It only means that
some tests little (less that 1%) slower while some faster. The biggest
difference is about 2.3%, so +/- 2.5% - that's what I mean. Anyway,
all that performance measurements are related to both kernel and
toolchain.
We will run all tests again before new submission. If you'd like to
see some specific test in addition to ones we already have - just let
me know.
> - I'm not familiar with the trinity benchmark. For posterity in this
> mailing list archive - can you post a link to it and do you have / can
> you post the analysis for this swing in performance ?
> I'm surprised
> that this has an impact on performance on lp64 and if so what
> circumstances do you see this performance loss and for what type of
> workloads ? Is trinity a synthetic benchmark which typically has
> noise in it that this swing of +/-5% is acceptable ?
> - what's the impact on standard lp64 benchmarks? Are we going to see a
> loss in performance for benchmarks like SPECCPU - I don't see why
> there should be any performance degradation - but if so can you
> explain why ?
Trinity is a syscall fuzzer. The program pushes random data to
syscalls and checks if kernel survives after it.
https://codemonkey.org.uk/projects/trinity/
I'm not too familiar with it as well. What I do is running trinity for
a long period - weekend or bigger, and check how kernel feels after it.
As I see, people usually do similar things. If there is some obvious
error in some syscall, 1000 calls of it with different parameters
should highlight the problem. I didn't find something like this.
Yury