[RFC 0/3] Asynchronous EEH recovery

Ganesh G R ganeshgr at linux.ibm.com
Mon Jul 17 18:10:01 AEST 2023

On 6/13/23 8:06 AM, Oliver O'Halloran wrote:

> On Tue, Jun 13, 2023 at 11:44 AM Ganesh Goudar<ganeshgr at linux.ibm.com>  wrote:
>> Hi,
>> EEH recovery is currently serialized and these patches shorten
>> the time taken for EEH recovery by making the recovery to run
>> in parallel. The original author of these patches is Sam Bobroff,
>> I have rebased and tested these patches.
>> On powervm with 64 VFs from same PHB,  I see approximately 48%
>> reduction in time taken in EEH recovery.
>> On powernv with 9 network cards, Where 2 cards installed on one
>> PHB and 1 card on each of the rest of the PHBs, Providing 20 PFs
>> in total. I see approximately 33% reduction in time taken in EEH
>> recovery.
>> These patches were originally posted as separate RFCs by Sam, And
>> I rebased and posted these patches almost a year back, I stopped
>> pursuing these patches as I was not able test this on powernv, Due
>> to the issues in drivers of cards I was testing this on, Which are
>> now resolved. Since I am re-posting this after long time, Posting
>> this as a fresh RFC, Please comment.
> What changes have you made since the last time you posted this series?
> If the patches are the same then the comments I posted last time still
> apply.

Hi Oliver, You asked about the way we are testing this on powervm, You expressed
concerns about having this on powernv, suggested to have this feature just for
powervm for now, and also expressed concerns on having two locks.

On powervm using two port card we are instantiating 64 VFS, for an lpar and injecting
the error on the bus from phyp, to observe the behavior.
I was able to test this on powernv with 16 PFs from 8 cards installed on separate PHBs,
Where I saw considerable performance improvement.
Regarding two locks idea, I may not have tested it for all scenarios, So far I have not
faced any issue, Are you suggesting a different approach.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20230717/d48c3251/attachment.htm>

More information about the Linuxppc-dev mailing list