public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Dong, Eric" <eric.dong@intel.com>
To: Laszlo Ersek <lersek@redhat.com>,
	"edk2-devel@lists.01.org" <edk2-devel@lists.01.org>
Cc: "Ni, Ruiyu" <ruiyu.ni@intel.com>
Subject: Re: [Patch v3 1/3] UefiCpuPkg/MpInitLib: Remove redundant CpuStateFinished State.
Date: Wed, 25 Jul 2018 11:15:29 +0000	[thread overview]
Message-ID: <ED077930C258884BBCB450DB737E66224AC5A5B3@shsmsx102.ccr.corp.intel.com> (raw)
In-Reply-To: <191141df-1a1a-0228-9055-86fa8982287e@redhat.com>

Hi Laszlo,


> -----Original Message-----
> From: Laszlo Ersek [mailto:lersek@redhat.com]
> Sent: Wednesday, July 25, 2018 6:55 PM
> To: Dong, Eric <eric.dong@intel.com>; edk2-devel@lists.01.org
> Cc: Ni, Ruiyu <ruiyu.ni@intel.com>
> Subject: Re: [edk2] [Patch v3 1/3] UefiCpuPkg/MpInitLib: Remove redundant
> CpuStateFinished State.
> 
> Hi Eric,
> 
> On 07/25/18 09:50, Eric Dong wrote:
> > Current CPU state definition include CpuStateIdle and CpuStateFinished.
> > After investigation, current code can use CpuStateIdle to replace the
> > CpuStateFinished. It will reduce the state number and easy for maintenance.
> >
> > Cc: Laszlo Ersek <lersek@redhat.com>
> > Cc: Ruiyu Ni <ruiyu.ni@intel.com>
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Eric Dong <eric.dong@intel.com>
> > ---
> >  UefiCpuPkg/Library/MpInitLib/MpLib.c | 18 ++++++++----------
> > UefiCpuPkg/Library/MpInitLib/MpLib.h |  1 -
> >  2 files changed, 8 insertions(+), 11 deletions(-)
> 
> After looking over this patch, it seems that you are preserving the
> CpuStateReady enum constant, relative to:
> 
>   http://mid.mail-archive.com/20180628112920.5296-1-eric.dong@intel.com
> 
> However, based on your analysis in
> 
>   http://mid.mail-
> archive.com/ED077930C258884BBCB450DB737E66224AC5A453@shsmsx102.
> ccr.corp.intel.com
> 
> isn't it still possible to run into the exact same issue? (Namely, BSP thinks the
> AP has gone through Idle -> Busy -> Idle, but the AP has never actually left
> Idle?)
> 
> Hm, wait, is it the case that the BSP first sets Ready, and so if the check for an
> AP returns Idle, it implies the AP must have gone through:
> 
>   Idle ----> Ready ----> Busy ----> Idle
> 
> ?

Correct! The Ready state is begin state and the Idle is the finish state.

> 
> If this is correct, can you please include the following in the commit
> message:
> 
> > Before this patch, the state transitions for an AP are:
> >
> >   Idle ----> Ready ----> Busy ----> Finished ----> Idle
> >        [BSP]       [AP]       [AP]           [BSP]
> >
> > After the patch, the state transitions for an AP are:
> >
> >   Idle ----> Ready ----> Busy ----> Idle
> >        [BSP]       [AP]       [AP]
> 
> Do you agree?

Good suggestion,  I will include this info in the commit message.

> 
> I have another question:
> 
> On 07/25/18 09:50, Eric Dong wrote:
> > diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.c
> > b/UefiCpuPkg/Library/MpInitLib/MpLib.c
> > index c82b985943..ff09a0e9e7 100644
> > --- a/UefiCpuPkg/Library/MpInitLib/MpLib.c
> > +++ b/UefiCpuPkg/Library/MpInitLib/MpLib.c
> > @@ -696,7 +696,7 @@ ApWakeupFunction (
> >              }
> >            }
> >          }
> > -        SetApState (&CpuMpData->CpuData[ProcessorNumber],
> CpuStateFinished);
> > +        SetApState (&CpuMpData->CpuData[ProcessorNumber],
> > + CpuStateIdle);
> >        }
> >      }
> >
> > @@ -1352,18 +1352,17 @@ CheckThisAP (
> >    CpuData   = &CpuMpData->CpuData[ProcessorNumber];
> >
> >    //
> > -  //  Check the CPU state of AP. If it is CpuStateFinished, then the AP has
> finished its task.
> > +  //  Check the CPU state of AP. If it is CpuStateIdle, then the AP has
> finished its task.
> >    //  Only BSP and corresponding AP access this unit of CPU Data.
> > This means the AP will not modify the
> > -  //  value of state after setting the it to CpuStateFinished, so BSP can safely
> make use of its value.
> > +  //  value of state after setting the it to CpuStateIdle, so BSP can safely
> make use of its value.
> >    //
> >    //
> >    // If the AP finishes for StartupThisAP(), return EFI_SUCCESS.
> >    //
> > -  if (GetApState(CpuData) == CpuStateFinished) {
> > +  if (GetApState(CpuData) == CpuStateIdle) {
> >      if (CpuData->Finished != NULL) {
> >        *(CpuData->Finished) = TRUE;
> >      }
> > -    SetApState (CpuData, CpuStateIdle);
> >      return EFI_SUCCESS;
> >    } else {
> >      //
> > @@ -1420,14 +1419,13 @@ CheckAllAPs (
> >
> >      CpuData = &CpuMpData->CpuData[ProcessorNumber];
> >      //
> > -    // Check the CPU state of AP. If it is CpuStateFinished, then the AP has
> finished its task.
> > +    // Check the CPU state of AP. If it is CpuStateIdle, then the AP has
> finished its task.
> >      // Only BSP and corresponding AP access this unit of CPU Data. This
> means the AP will not modify the
> > -    // value of state after setting the it to CpuStateFinished, so BSP can
> safely make use of its value.
> > +    // value of state after setting the it to CpuStateIdle, so BSP can safely
> make use of its value.
> >      //
> > -    if (GetApState(CpuData) == CpuStateFinished) {
> > +    if (GetApState(CpuData) == CpuStateIdle) {
> >        CpuMpData->RunningCount ++;
> >        CpuMpData->CpuData[ProcessorNumber].Waiting = FALSE;
> > -      SetApState(CpuData, CpuStateIdle);
> >
> >        //
> >        // If in Single Thread mode, then search for the next waiting AP for
> execution.
> 
> This part of the code, after the patch, does not seem idempotent; in other
> words, if the BSP calls CheckAllAPs() multiple times, then RunningCount will
> be increased every time. Before the patch, this wasn't the case, because after
> the Finished -> Idle transition, the increment wouldn't be reached again.
> 
> Hmmm, wait, I'm wrong: we set the Waiting field to FALSE as well, so at the
> next call to CheckAllAPs(), we'll take the early "continue" branch.
> Looks OK after all.
> 

Yes, we have two flags here.  Waiting flags means the AP will do the task. State flag means whether the task has finished.
Both flags will be checked and updated.

> I'll follow up with test results.
> 
> Thanks,
> Laszlo
> 
> > @@ -1923,7 +1921,7 @@ SwitchBSPWorker (
> >    //
> >    // Wait for old BSP finished AP task
> >    //
> > -  while (GetApState (&CpuMpData->CpuData[CallerNumber]) !=
> > CpuStateFinished) {
> > +  while (GetApState (&CpuMpData->CpuData[CallerNumber]) !=
> > + CpuStateIdle) {
> >      CpuPause ();
> >    }
> >
> > diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.h
> > b/UefiCpuPkg/Library/MpInitLib/MpLib.h
> > index 9d0b866d09..962bce685d 100644
> > --- a/UefiCpuPkg/Library/MpInitLib/MpLib.h
> > +++ b/UefiCpuPkg/Library/MpInitLib/MpLib.h
> > @@ -85,7 +85,6 @@ typedef enum {
> >    CpuStateIdle,
> >    CpuStateReady,
> >    CpuStateBusy,
> > -  CpuStateFinished,
> >    CpuStateDisabled
> >  } CPU_STATE;
> >
> >


  reply	other threads:[~2018-07-25 11:17 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-25  7:50 [Patch V3 0/3] StartAllAPs should not use disabled APs Eric Dong
2018-07-25  7:50 ` [Patch v3 1/3] UefiCpuPkg/MpInitLib: Remove redundant CpuStateFinished State Eric Dong
2018-07-25 10:54   ` Laszlo Ersek
2018-07-25 11:15     ` Dong, Eric [this message]
2018-07-26  5:18       ` Ni, Ruiyu
2018-07-25  7:50 ` [Patch v3 2/3] UefiCpuPkg/MpInitLib: Remove StartCount and volatile definition Eric Dong
2018-07-25 11:47   ` Laszlo Ersek
2018-07-25 12:09     ` Dong, Eric
2018-07-25 15:18       ` Laszlo Ersek
2018-07-26  5:22   ` Ni, Ruiyu
2018-07-25  7:50 ` [Patch v3 3/3] UefiCpuPkg/MpInitLib: Not use disabled AP when call StartAllAPs Eric Dong
2018-07-25 12:11   ` Laszlo Ersek
2018-07-25 12:44     ` Dong, Eric
2018-07-26  8:36   ` Ni, Ruiyu
2018-07-26  8:36     ` Ni, Ruiyu
2018-07-25 12:12 ` [Patch V3 0/3] StartAllAPs should not use disabled APs Laszlo Ersek
2018-07-25 15:18   ` Laszlo Ersek

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-list 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=ED077930C258884BBCB450DB737E66224AC5A5B3@shsmsx102.ccr.corp.intel.com \
    --to=devel@edk2.groups.io \
    /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