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