[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    [W:0.023 / U:6.484 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site