Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S266056AbUA1Tdm (ORCPT ); Wed, 28 Jan 2004 14:33:42 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S266037AbUA1Tdl (ORCPT ); Wed, 28 Jan 2004 14:33:41 -0500 Received: from fw.osdl.org ([65.172.181.6]:9128 "EHLO mail.osdl.org") by vger.kernel.org with ESMTP id S266044AbUA1Tdi (ORCPT ); Wed, 28 Jan 2004 14:33:38 -0500 Date: Wed, 28 Jan 2004 11:33:33 -0800 (PST) From: Linus Torvalds To: Matthew Wilcox cc: Hironobu Ishii , linux-kernel , linux-ia64 Subject: Re: [RFC/PATCH, 2/4] readX_check() performance evaluation In-Reply-To: <20040128182003.GL11844@parcelfarce.linux.theplanet.co.uk> Message-ID: References: <00a301c3e541$c13a6350$2987110a@lsd.css.fujitsu.com> <20040128182003.GL11844@parcelfarce.linux.theplanet.co.uk> 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 Content-Length: 1286 Lines: 29 On Wed, 28 Jan 2004, Matthew Wilcox wrote: > > If there are, Linus' interface is probably the best one. If not, we could > simply have readX_check() / writeX_check() call dev->driver->unregister() > if they notice an error has occurred and then the driver doesn't even > need to call read_pcix_errors(). What worries me is that not only can the errors be asynchronous, they may well be relatively expensive to check for. For example, if checking for an error involves actually reading a value from a bridge register, then that implies some _serious_ amount of serialization and external CPU stuff. The advantage of having the "check for errors" be done later and independently of the actual IO access itself is not only that I think it makes the code look nicer - it also allows you to do the IO independently of the check. Which potentially means that the CPU can burst out the writes as a burst write, rather than doing them one at a time and then doing a read of a bridge register in between that serializes everything. Linus - 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/