Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758249AbYAJJoR (ORCPT ); Thu, 10 Jan 2008 04:44:17 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754440AbYAJJoF (ORCPT ); Thu, 10 Jan 2008 04:44:05 -0500 Received: from py-out-1112.google.com ([64.233.166.182]:53740 "EHLO py-out-1112.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753024AbYAJJoE (ORCPT ); Thu, 10 Jan 2008 04:44:04 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=QXBYxCchtEkBU7cyu6teyOL/iemzcvsTFe8+JZEaN7vxKrtMSNBXl/1bbjnCjvvJjyKEawl5DCvnCbBI4EnmM0OFNFj4mQ0Pa62jlWZbfblmyD8+aoIT9/oZvanKEXv9ng1gc75znhUjvMoryRohCIo0eaWhjkn4qmXsKxU019A= Message-ID: <21d7e9970801100144x63b02e1bga548acd3c5bed441@mail.gmail.com> Date: Thu, 10 Jan 2008 19:44:03 +1000 From: "Dave Airlie" To: "Ingo Molnar" Subject: Re: CPA patchset Cc: "Andi Kleen" , linux-kernel@vger.kernel.org, "Thomas Gleixner" , "H. Peter Anvin" , "Venki Pallipadi" , suresh.b.siddha@intel.com, "Arjan van de Ven" , "Dave Jones" In-Reply-To: <20080110093126.GA360@elte.hu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080103424.989432000@suse.de> <20080110093126.GA360@elte.hu> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1147 Lines: 25 > > finally managed to get the time to review your CPA patchset, and i > fundamentally agree with most of the detail changes done in it. But here > are a few structural high-level observations: > > - firstly, there's no rationale given. So we'll change ioremap()/etc. > from doing a cflush-range instruction instead of a WBINVD. But why? > WBINVD isnt particular fast (takes a few msecs), but why is that a > problem? Drivers dont do high-frequency ioremap-ing. It's typically > only done at driver/device startup and that's it. Whether module load > time takes 1254 msecs instead of 1250 msecs is no big deal. read graphics drivers, even though I think we may avoid the whole path if we can and end up doing some of this in the drivers when they know more about the situation so can avoid safeties.. but I still see this being used in AGP a fair bit at some point on some drivers.. Dave. -- 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/