linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Gavin Shan <gwshan@linux.vnet.ibm.com>
Cc: linuxppc-dev@lists.ozlabs.org, wenxiong@linux.vnet.ibm.com,
	Brian J King <bjking1@us.ibm.com>
Subject: Re: [PATCH] powerpc/pseries: Avoid context switch in EEH reset if required
Date: Sat, 24 Jan 2015 10:57:30 +0100	[thread overview]
Message-ID: <1422093450.4949.89.camel@kernel.crashing.org> (raw)
In-Reply-To: <20150123035029.GA19657@shangw>

On Fri, 2015-01-23 at 14:50 +1100, Gavin Shan wrote:

> Messages from Brian for reference:
> 
> | The API has changed. I wrote the pci_set_pcie_reset_state API originally.
> | When this API was put in place initially, it was perfectly legal to call it
> | from an atomic context. Can you clarify why we have to have the delay in the
> | pci_set_pcie_reset_state function? Shouldn't it be the responsibility of the
> | callers to ensure a proper delay is used? This was always the case until
> | recently.
> 
> So please ignore this patch and I'll send another one, which is implemented in
> above approach.

I still think it's not a great idea to allow that API to be called in
atomic context.

Brian, the reset API for PCIe involves FW calls which might have to do
a bunch of stuff under the hood, including potentially significant
delays.

For example, under OPAL (and I suppose PowerVM), if doing a PERST, the
API calls will loop until the link is back up, at least when "releasing"
the reset line.

I wouldn't be surprised if on x86, similar kinds of ACPI calls are
needed which may not be the best thing to do in atomic context.

I don't see any specific performance issues with issuing resets, so I
would strongly advocate for changing the API requirements instead so
that it's called from a task context.

Cheers,
Ben.



> Thanks,
> Gavin
> 
> >>>> Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
> >>>> Tested-by: Wen Xiong<wenxiong@linux.vnet.ibm.com>
> >>>> ---
> >>>>  arch/powerpc/platforms/pseries/eeh_pseries.c | 12 ++++++++----
> >>>>  1 file changed, 8 insertions(+), 4 deletions(-)
> >>>> 
> >>>> diff --git a/arch/powerpc/platforms/pseries/eeh_pseries.c b/arch/powerpc/platforms/pseries/eeh_pseries.c
> >>>> index a6c7e19..67623a3 100644
> >>>> --- a/arch/powerpc/platforms/pseries/eeh_pseries.c
> >>>> +++ b/arch/powerpc/platforms/pseries/eeh_pseries.c
> >>>> @@ -503,8 +503,7 @@ static int pseries_eeh_get_state(struct eeh_pe *pe, int *state)
> >>>>   */
> >>>>  static int pseries_eeh_reset(struct eeh_pe *pe, int option)
> >>>>  {
> >>>> -	int config_addr;
> >>>> -	int ret;
> >>>> +	int config_addr, delay, ret;
> >>>>  
> >>>>  	/* Figure out PE address */
> >>>>  	config_addr = pe->config_addr;
> >>>> @@ -528,9 +527,14 @@ static int pseries_eeh_reset(struct eeh_pe *pe, int option)
> >>>>  	/* We need reset hold or settlement delay */
> >>>>  	if (option == EEH_RESET_FUNDAMENTAL ||
> >>>>  	    option == EEH_RESET_HOT)
> >>>> -		msleep(EEH_PE_RST_HOLD_TIME);
> >>>> +		delay = EEH_PE_RST_HOLD_TIME;
> >>>> +	else
> >>>> +		delay = EEH_PE_RST_SETTLE_TIME;
> >>>> +
> >>>> +	if (in_atomic())
> >>>> +		udelay(delay * 1000);
> >>>>  	else
> >>>> -		msleep(EEH_PE_RST_SETTLE_TIME);
> >>>> +		msleep(delay);
> >>>>  
> >>>>  	return ret;
> >>>>  }
> >>>
> >>>

  reply	other threads:[~2015-01-24  9:57 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-18 22:47 [PATCH] powerpc/pseries: Avoid context switch in EEH reset if required Gavin Shan
2015-01-20  9:28 ` Benjamin Herrenschmidt
2015-01-20 22:56   ` Gavin Shan
2015-01-20 23:53     ` Gavin Shan
2015-01-23  3:50       ` Gavin Shan
2015-01-24  9:57         ` Benjamin Herrenschmidt [this message]
2015-01-26 23:36           ` Brian King
2015-01-27  4:31             ` Benjamin Herrenschmidt
2015-01-27 22:58               ` Brian King
2015-01-27 23:58                 ` Benjamin Herrenschmidt
2015-01-30  1:37                   ` Gavin Shan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1422093450.4949.89.camel@kernel.crashing.org \
    --to=benh@kernel.crashing.org \
    --cc=bjking1@us.ibm.com \
    --cc=gwshan@linux.vnet.ibm.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=wenxiong@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).