Revert "Detect cache line size on Linux for PPC hosts."

Revert "Detect cache line size on Linux for PPC hosts."

along with "[arm64] Fix i/d cache line size confusion typo"
and "Fix a warning about inline asm source/destination mismatches..."
which were building on it.

This reverts the following commits:
8d7399f9f8688a93137ced9e084bccb8cc1b075c
474e6a3d6d3482b97c8307e45bb314f6e50bfc3c
c3ff68b6b76ff1ffa1f6cd7c82181366020a0fe2

Reason for revert: We're getting a large number of crash reports from
arm64 devices that are obviously related to cache flushing after code
patching. Bisection results say that the problems started at revision
c3ff68b. Since I can't find a bug in that CL except for the typo that
I've fixed in 474e6a3 (which made some of the crashes go away but not
all of them), we have no choice but to revert the changes in order to
get stability under control while we investigate.

BUG=chromium:594646
LOG=n

Committed: https://crrev.com/5d62db7430d48e112ddda7178419dc63adb32620
Cr-Commit-Position: refs/heads/master@{#34816}

[Jakob Kummerow, 2016-03-16 12:19:56]

jkummerow@chromium.org changed reviewers:
+ yangguo@chromium.org

[Jakob Kummerow, 2016-03-16 12:19:57]

Yang: PTAL (clean revert + git-cl-format, no manual changes, no conflicts)

Michael: FYI.

echristo: We'll have to re-apply your warning fix (if this revert helps and
stays in). Sorry.

PPC team: FYI. Feel free to re-land the PPC-specific parts of this.

If anyone can tell me which part of this revert actually changes cache flushing
behavior on arm64, they'll get a cookie, 'cause I don't see it...

[Yang, 2016-03-16 12:20:56]

On 2016/03/16 12:19:57, Jakob wrote:
> Yang: PTAL (clean revert + git-cl-format, no manual changes, no conflicts)
> 
> Michael: FYI.
> 
> echristo: We'll have to re-apply your warning fix (if this revert helps and
> stays in). Sorry.
> 
> PPC team: FYI. Feel free to re-land the PPC-specific parts of this.
> 
> If anyone can tell me which part of this revert actually changes cache
flushing
> behavior on arm64, they'll get a cookie, 'cause I don't see it...

LGTM (rubberstamp).

[Jakob Kummerow, 2016-03-16 12:21:32]

The CQ bit was checked by jkummerow@chromium.org

[commit-bot: I haz the power, 2016-03-16 12:21:41]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1806853002/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1806853002/1

[Jakob Kummerow, 2016-03-16 12:46:25]

> If anyone can tell me which part of this revert actually changes cache 
> flushing behavior on arm64, they'll get a cookie, 'cause I don't
> see it...

Yang suggested that on a big.LITTLE architecture, the two kinds of cores could
have different cache line sizes, which would indeed explain why getting the
cache line size immediately before using it (like V8 used to do, and will do
again after this revert) works fine, whereas caching the cache line sizes (like
c3ff68b did) is generally not safe.

Rodolph, does that make sense?

[commit-bot: I haz the power, 2016-03-16 13:04:56]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-03-16 13:04:57]

Try jobs failed on following builders:
  v8_linux_arm64_rel on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux_arm64_rel/builds/1...)

[Jakob Kummerow, 2016-03-16 13:16:29]

The CQ bit was checked by jkummerow@chromium.org

[commit-bot: I haz the power, 2016-03-16 13:16:36]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1806853002/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1806853002/1

[commit-bot: I haz the power, 2016-03-16 13:49:44]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-03-16 13:50:33]

Description was changed from

==========
Revert "Detect cache line size on Linux for PPC hosts."

along with "[arm64] Fix i/d cache line size confusion typo"
and "Fix a warning about inline asm source/destination mismatches..."
which were building on it.

This reverts the following commits:
8d7399f9f8688a93137ced9e084bccb8cc1b075c
474e6a3d6d3482b97c8307e45bb314f6e50bfc3c
c3ff68b6b76ff1ffa1f6cd7c82181366020a0fe2

Reason for revert: We're getting a large number of crash reports from
arm64 devices that are obviously related to cache flushing after code
patching. Bisection results say that the problems started at revision
c3ff68b. Since I can't find a bug in that CL except for the typo that
I've fixed in 474e6a3 (which made some of the crashes go away but not
all of them), we have no choice but to revert the changes in order to
get stability under control while we investigate.

BUG=chromium:594646
LOG=n
==========

to

==========
Revert "Detect cache line size on Linux for PPC hosts."

along with "[arm64] Fix i/d cache line size confusion typo"
and "Fix a warning about inline asm source/destination mismatches..."
which were building on it.

This reverts the following commits:
8d7399f9f8688a93137ced9e084bccb8cc1b075c
474e6a3d6d3482b97c8307e45bb314f6e50bfc3c
c3ff68b6b76ff1ffa1f6cd7c82181366020a0fe2

Reason for revert: We're getting a large number of crash reports from
arm64 devices that are obviously related to cache flushing after code
patching. Bisection results say that the problems started at revision
c3ff68b. Since I can't find a bug in that CL except for the typo that
I've fixed in 474e6a3 (which made some of the crashes go away but not
all of them), we have no choice but to revert the changes in order to
get stability under control while we investigate.

BUG=chromium:594646
LOG=n

Committed: https://crrev.com/5d62db7430d48e112ddda7178419dc63adb32620
Cr-Commit-Position: refs/heads/master@{#34816}
==========

[commit-bot: I haz the power, 2016-03-16 13:50:34]

Patchset 1 (id:??) landed as
https://crrev.com/5d62db7430d48e112ddda7178419dc63adb32620
Cr-Commit-Position: refs/heads/master@{#34816}

[baptiste.afsa1, 2016-03-16 15:03:22]

On 2016/03/16 12:46:25, Jakob wrote:
> > If anyone can tell me which part of this revert actually changes cache 
> > flushing behavior on arm64, they'll get a cookie, 'cause I don't
> > see it...
> 
> Yang suggested that on a big.LITTLE architecture, the two kinds of cores could
> have different cache line sizes, which would indeed explain why getting the
> cache line size immediately before using it (like V8 used to do, and will do
> again after this revert) works fine, whereas caching the cache line sizes
(like
> c3ff68b did) is generally not safe.
> 
> Rodolph, does that make sense?

Hi Jakob,

We are looking at this issue but it's pretty hard to guess what's happening
here without more information. Do you have more details on the devices which
are affected by this regression that you could share with us?