Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759927AbYCYXCe (ORCPT ); Tue, 25 Mar 2008 19:02:34 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1758000AbYCYXCQ (ORCPT ); Tue, 25 Mar 2008 19:02:16 -0400 Received: from terminus.zytor.com ([198.137.202.10]:40947 "EHLO terminus.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757954AbYCYXCP (ORCPT ); Tue, 25 Mar 2008 19:02:15 -0400 Message-ID: <47E9843A.1060702@zytor.com> Date: Tue, 25 Mar 2008 16:01:14 -0700 From: "H. Peter Anvin" User-Agent: Thunderbird 2.0.0.12 (X11/20080226) MIME-Version: 1.0 To: Ingo Molnar CC: Venki Pallipadi , Yinghai Lu , Thomas Gleixner , Andrew Morton , kernel list , suresh.b.siddha@intel.com Subject: Re: [PATCH] x86: pat cpu feature bit setting for known cpus References: <200803242324.35357.yhlu.kernel@gmail.com> <47E9003B.5010002@zytor.com> <86802c440803251103taf4c8f2mb674c3d17f3c2345@mail.gmail.com> <20080325190851.GC30998@linux-os.sc.intel.com> <20080325200830.GB15330@elte.hu> <47E962AE.9040307@zytor.com> In-Reply-To: <47E962AE.9040307@zytor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1400 Lines: 33 H. Peter Anvin wrote: > Ingo Molnar wrote: >> * Venki Pallipadi wrote: >> >>>>> OK, note previous question: what is the motivation for having >>>>> this as a whitelist (as opposed to a blacklist)? >>>> Venkatesh could tell? >>> Main reason for white-list at this point is not to be side-tracked by >>> real or potential erratas on older CPUs. Focussing on getting the >>> support for this feature on current and future CPUs. If older CPUs >>> have survived all these days without this feature, they should be >>> doing OK. >> >> well, the upside would be that since most testing of Linux kernels is >> done on _old_ hardware (people tend to risk their old hw first ;-), >> we'd get faster convergence of the codebase, even though we have the >> risk of erratas (known and unknown ones alike). Code that artificially >> limits its utility is almost always slow to stabilize. >> > > Yes, using a whitelist of this type is wrong, IMO, and smells faintly of > vendor-lockin. > By the way, I want to clarify: I didn't mean it was *intended* as vendor-lockin, just that it's an undesirable effect of this. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/