lkml.org 
[lkml]   [2016]   [Oct]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] x86/AMD: Apply erratum 688 on machines without a BIOS fix

> so that doesn't tell me a whole lot.
It does to me! That cpu family is "broken" both on B0 and C0. I think
that a CPU at 30% load should not have >31% branch misses. For example
with 5% CPU usage you can't expect to get 10% branch-misses...

> Well, Ontario is a small core and with the erratum workaround in place,
> it does get a bit worse too, apparently.
Yes but on C0 I got better results. Maybe the BIOS vendor got similar
results and did not apply the fix. They use the same BIOS for all
machines B0, C0 and that could be the reason for not applying the 688
workaround.
I think we are going to the wrong place here but I will not try to
influence you at all. I only apply the fix once per boot and I think
that we are not supposed to apply, remove and then reapply workarounds
on the fly. Be carefull, you might hang your machine, brick your board
or destroy your APU!

The truth is that my system behaves better with the patch.

The problem is that there is no way to get what I need! That is the
E-300 datasheet...They give everything for the north and the south but
we have poor documentation for the APU itself...I will contact AMD to
see if I can get the APU datasheet so that we have a clue what those
bits actualy do.

> Hohumm, yeah, the workaround impacts the number of branch misses. It
> probably disables some branch predictor optimization or so, which is
> "problematic" in certain scenarios.
That is obvious. You can't say what it does, it might disable an
internal buffer or force a CPU subsystem to run at a lower frequency,
who knows?

> I guess we still want it because first we should not explode and then
> go
> fast :)
Exactly. I agree with that as I want to eliminate the crashes. Keep in
mind that speed is something that all those APUs do not have and will
never have, stability is what we are trying to improve.

> I'm thinking currently that if it is not easily triggerable, I could
> make the erratum workaround off by default and have a command line
> option which people can enable in case they experience any of the
> issues...
No problem, it is up to you. As I said above, I will not try to change
your mind.

\
 
 \ /
  Last update: 2016-10-24 22:40    [W:0.152 / U:0.088 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site