Discussion:
[ACTIVITY] 16th - 20th March
Bernie Ogden
2015-03-23 09:18:25 UTC
Permalink
catomics - TCWG-436 [6/10]
* Started a series of runs on a local board I'd borrowed
** Then had to give it back before they'd really got anywhere
* Got some, possibly dubious, results back from A15 from previous week
** If the results are worth anything, they suggest that catomics don't
achieve anything
* Started again with a subset of SPEC on juno-01, as it was on my desk
for the weekend anyway
** Results again underwhelming
** Maybe I picked the wrong subset, maybe A57 is too smart

Misc [4/10]
* Including a little 'juno cache effects' followup, a little juno-01
work, and a lot of mail catchup


=Plan=

* Get back to benchmark automation
** Apply a bunch of small improvements I've got on a branch
** Get a working Jenkins backport benchmarking prototype
** Sort out sources/results storage

* Think about why catomics may not be showing any effect
** Starting to believe that this is a red herring
** But might be interesting to try 'little' class cores
** But that does involve finding a reliable target I can hold for a long time
Venkataramanan Kumar
2015-03-23 10:05:25 UTC
Permalink
ASAN/TSAN run on 42 bit VA Aarch64 with 64 bit allocators (TCWG-634) (6/10)
* Juno does not have space for kernel allocator map demanded by
ASAN, So we need to remain on 32 bit allocators only.
* amd-01 went offline. So moved to internal machine in AMD.
Debugging LLVM test failures in GDB showed that ASLR should be
turned off and also the shadow offset is set at 1<<36 and is not
changing when I fix it in asan_mappings.h file .
Manually changing shadow offset to 1<<39 fixes some segfaults.

Bug869: Continued to look at ABS_EXPR cases (2/10).

* Emails, meetings. (2/10)
* Linaro 1-1 with christophe, Ryan
* AMD meetings/event, 1-1 with AMD manager, status meeting.
* GCC mailing list.

== Plan ==
*Continue to fix TSAN/ASAN 64 bit allocator failures on amd-01 .
* Bug869

Loading...