Re: [PATCH 2.6.13] IOCHK interface for I/O error handling/detecting

Hidetoshi Seto
2005-09-03T09:36:56Z

Matthew Wilcox wrote:
> On Thu, Sep 01, 2005 at 05:45:54PM -0500, Brent Casavant wrote:
>
>>I am extremely concerned about the performance implications of this
>>implementation. These changes have several deleterious effects on I/O
>>performance.
>
>
> I agree. I think the iochk patches should be abandoned and the feature
> reimplemented on top of the asynchronous PCI error notification patches
> from Linas Vepstas.

Do you mean that all architecture especially other than PPC64 already
have enough synchronization point or enough infrastructure to invoke
those notifiers effectively? I don't think so.

As far as I know, PPC64 is enveloped by a favorable situation.
At least in situation of readX and inX on PPC64, they already have
a error check point, and the EEH technology and the firmware make their
error recovery easier.
Because PPC64 firmware (or hardware? - I'm not sure) automatically detects
errors, isolates erroneous device and returns "(type)~0" to kernel,
readX/inX doesn't need to do any expensive thing unless it get "(type)~0."
Therefore PPC64 can have a nice chance to invoke notifiers by extending
the codes in the error check point.
It is clear that doing same thing on other architecture will be quite
painful and expensive.

Why don't you think that it would be useful if the error notifier
could be invoked from iochk_read()? I believe the iochk patches
will help implementing PCI error notification on not only IA64 but
also i386 and so on.
Or do you mean we would be happy if we all have a PPC64 box?

Thanks,
H.Seto