[lkml]   [2004]   [Jan]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
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:

x = readX_check(dev, offset); /* Maybe several ones, maybe in a loop */
error = read_pcix_errors(dev);
if (error)
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

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

Does anybody see any downsides to something like this?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2009-11-18 23:46    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean