Re: [PATCH 12/12] libata: implement EH fast drain

[Tejun Heo <htejun@gmail.com>]

Jeff Garzik wrote:
> Tejun Heo wrote:
>> In most cases, when EH is scheduled, all in-flight commands are
>> aborted causing EH to kick in immediately.  However, in some cases
>> (especially with PMP), it's unclear which commands are affected by the
>> error condition and although aborting all in-flight commands work, it
>> isn't optimal and may cause unnecessary disruption.  On the other
>> hand, waiting for in-flight commands to drain themselves can take up
>> to 30seconds.
>>
>> This patch implements EH fast drain to handle such situations.  It
>> gives in-flight commands some time to finish up but doesn't wait for
>> too long.  After EH is scheduled, fast drain timer is started and if
>> no other completion occurs in ATA_EH_FASTDRAIN_INTERVAL all in-flight
>> commands are aborted.  If any completion occurred in the interval, the
>> port is given another interval to finish up itself.
>>
>> Currently ATA_EH_FASTDRAIN_INTERVAL is 3 secs which should be enough
>> for finishing up most commands.
>>
>> Signed-off-by: Tejun Heo <htejun@gmail.com>
> 
> what type of errors are we talking about?  device errors can be handled
> on a more granular basis than other errors.

On standalone (non-PMP) port, this doesn't matter because in-flight
commands are always aborted when error occurs.  Fast drain helps when
PMP is involved.  For example, after certain event, PMP can notify host
that something is off via SDB notify but until EH kicks in and performs
autopsy, there's no way to tell to which port the event happened.

If there were in-flight commands to the failed link and/or PMP chip went
for lunch after the event (it often does), EH is forced to wait for
timeout even though it knows something is off.  Fast drain helps in such
situations - ie. when EH knows something wrong is going on and it's very
likely that commands which aren't completing are going to timeout.

-- 
tejun