From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758706AbcJYJ3N (ORCPT ); Tue, 25 Oct 2016 05:29:13 -0400 Received: from mail.skyhub.de ([78.46.96.112]:36978 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758293AbcJYJ3K (ORCPT ); Tue, 25 Oct 2016 05:29:10 -0400 Date: Tue, 25 Oct 2016 11:29:08 +0200 From: Borislav Petkov To: sonofagun@openmailbox.org Cc: linux-kernel@vger.kernel.org, Nikos Barkas Subject: Re: [PATCH] x86/AMD: Apply erratum 688 on machines without a BIOS fix Message-ID: <20161025092908.2dho2asz5ucojogw@pd.tnic> References: <20161023095722.n77oefpmttzvzqqc@pd.tnic> <4b27ef7e7a256a6c9341cf182ebceef7@openmailbox.org> <20161023172530.buklz6ir56dmbvu7@pd.tnic> <78e7e3b73f5ad8af44710a0e104301cb@openmailbox.org> <20161023213939.d55y5yc2megztnyr@pd.tnic> <6ce351cda59585ecdfdce361d885811e@openmailbox.org> <20161024093510.od57fbvn5rsgxcua@pd.tnic> <714acbaa1350bfe8927ccbea2425f4a9@openmailbox.org> <20161024171450.yi6wixtdsxd4ea4c@pd.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20161014 (1.7.1) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 24, 2016 at 11:39:47PM +0300, sonofagun@openmailbox.org wrote: > 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... Why not? It all depends on the load type, working set and the access patterns. There's no strong correlation between the load of a machine and the amount of branch misses... > Yes but on C0 I got better results. Maybe the BIOS vendor got similar > results and did not apply the fix. Well, there's a C0 stepping which doesn't need the fix because it was fixed in the silicon. You can check that by doing: setpci -s 0x18.4 0x164.l and looking at bit 2. If it is set, the erratum is fixed. > 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. No, I don't mean that - I'm talking about *not* applying it by default and when people start seeing issues like that, they can boot their machines with something like "enable_e688_workaround" or so and it will get applied then. I.e., an "opt-in" deal. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply.