lkml.org 
[lkml]   [2004]   [Jan]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC/PATCH, 2/4] readX_check() performance evaluation


On Wed, 28 Jan 2004, Hironobu Ishii wrote:
>
> This is a readX_check() prototype patch to evaluate
> the performance disadvantage.

Quite frankly, I'd much rather have something more like this:

clear_pcix_errors(dev);
..
x = readX_check(dev, offset); /* Maybe several ones, maybe in a loop */
..
error = read_pcix_errors(dev);
if (error)
take_pcix_offline(dev);
in other words, I'd rather _not_ see the "readX_check()" code itself have
the retry logic and error value handling.

Why? Because on a number of architectures it is entirely possible that the
error comes as a _asynchronous_ machine exception or similar. So I'd much
rather have the interfaces be designed for that. Also, it's likely to
perform a lot better, and result in much clearer code this way (ie you can
try to set up the whole command before reading the error just once).

It is _also_ going to be a hell of a lot easier to disable the code if you
want to, with just a

#ifndef CONFIG_PCI_RECOVERY
#define clear_pcix_errors(dev) do { } while (0)
#define read_pcix_errors(dev) (0)
#define take_pcix_offline(dev) do { } while (0)
#endif
in a header file for architectures that don't support it.

Does anybody see any downsides to something like this?

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/

\
 
 \ /
  Last update: 2009-11-18 23:46    [from the cache]
©2003-2011 Jasper Spaans