From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261955AbTIRRnV (ORCPT ); Thu, 18 Sep 2003 13:43:21 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261971AbTIRRnV (ORCPT ); Thu, 18 Sep 2003 13:43:21 -0400 Received: from tmr-02.dsl.thebiz.net ([216.238.38.204]:51463 "EHLO gatekeeper.tmr.com") by vger.kernel.org with ESMTP id S261955AbTIRRnU (ORCPT ); Thu, 18 Sep 2003 13:43:20 -0400 Date: Thu, 18 Sep 2003 13:34:04 -0400 (EDT) From: Bill Davidsen To: Pavel Machek cc: richard.brunner@amd.com, alan@lxorguk.ukuu.org.uk, zwane@linuxpower.ca, linux-kernel@vger.kernel.org Subject: Re: [PATCH] 2.6 workaround for Athlon/Opteron prefetch errata In-Reply-To: <20030918074331.GA386@elf.ucw.cz> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 18 Sep 2003, Pavel Machek wrote: > > I think Alan brought up a very good point. Even if you > > use a generic kernel that avoids prefetch use on Athlon > > (which I am opposed to), it doesn't solve the problem > > of user space programs detecting that the ISA supports > > prefetch and using prefetch instructions and hitting the > > errata on Athlon. > > > > The user space problem worries me more, because the expectation > > is that if CPUID says the program can use perfetch, it could > > and should regardless of what the kernel decided to do here. > > User programs should not rely on cpuid; they should read /proc/cpuinfo > exactly because this kind of errata. That's fine, but impacts portability. I don't think there is a right way, since the o/s may not know about some features and the CPU may be optimistic. Unless they are "recent Linux only" programs they may well check the CPU itself, there are reasons for it in portable code. -- bill davidsen CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.