Re: Broken Build due to T1969

I can't reproduce it on my x86_64 Linux laptop when I boot GHC HEAD with GHC 7.10.2. Anyway, feel free to revert 773e3aad (which disables the test) but I think bumping the numbers a little bit is a better option here as that would at least prevent things from getting worse. I'm curious, does anyone know how much ram harbormaster has? I can't see from the logs how many times GC is running during T1969, but maybe GC is running less number of times which is causing the residency to increase. I'm also wondering if there are more stable ways of testing residency. Can we maybe do something like: runMajorGC >> printResidency In some specific locations in the compiler and only look for those in perf tests? Or does anyone have any better ideas? 2016-08-17 18:05 GMT+00:00 Ömer Sinan Ağacan :

Hmm, it seems to be a 64bit Linux. Interestingly peak_megabytes_allocated is also different than numbers I'm getting on my 64bit Linux laptop. Maybe this is because harbormaster is booting with GHC 7.10.3 and I'm booting with GHC 8.0.1. I'm currently validating with 7.10.3 to see if I'll get the same numbers.

2016-08-17 15:17 GMT+00:00 Matthew Pickering :

...

I am just seeing it on harbourmaster.

https://phabricator.haskell.org/harbormaster/build/12730/?l=100

Matt

On Wed, Aug 17, 2016 at 3:59 PM, Ömer Sinan Ağacan wrote:

...

Ugh. I validated that patch before committing and validated many times after that patch. Are you using a 32bit system? Maybe we should bump the numbers for 32bit builds too.

I'm hesitant to mark the test broken because I'm afraid that the numbers will increase if we stop testing for allocations/residency completely. I think temporarily bumping numbers is better than temporarily disabling it.

What are the numbers you're getting?

2016-08-17 14:16 GMT+00:00 Matthew Pickering :

...

Hi all,

https://phabricator.haskell.org/rGHC773e3aadac4bbee9a0173ebc90ffdc9458a2a3a9

broke the build by re-enabling the test T1969

The ticket tracking this is: https://ghc.haskell.org/trac/ghc/ticket/12437

Omer: Is it best to revert this patch and mark the test broken again?

Matt