public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Fan Jeff <vanjeff_919@hotmail.com>
To: "lersek@redhat.com" <lersek@redhat.com>,
	"eric.dong@intel.com" <eric.dong@intel.com>,
	"edk2-devel@lists.01.org" <edk2-devel@lists.01.org>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Subject: Re: 答复: [Patch] UefiCpuPkg/MpInitLib: Optimize get processor number performance.
Date: Thu, 5 Jul 2018 14:00:20 +0000	[thread overview]
Message-ID: <SN6PR19MB22694930D53F6AD6E8F3EE6FD7400@SN6PR19MB2269.namprd19.prod.outlook.com> (raw)

Laszlo,

Thanks your remind. You are right! I agree original commit message is correct and neednt updating.

Eric, please ignore my comments on commit message.

Thanks!
Jeff



发自我的小米手机
在 Laszlo Ersek <lersek@redhat.com>,2018年7月5日 下午9:04写道:

Hi Jeff,

On 07/04/18 11:39, Fan Jeff wrote:
> Eric,
>
> Current implementation does not call GetApicid() many times,  Please correct you commit message. Your fix is to improve the performance against the current implementation.

I think the original commit message does make sense. Without the patch,
GetProcessorNumber() may call GetApicId() up to TotalProcessorNumber
times. With the patch, even if we skip the stack range search,
GetProcessorNumber() will call GetApicId() just once.

[...]

Some more questions below, for the patch:

> 发件人: Eric Dong <eric.dong@intel.com>
> 发送时间: Wednesday, July 4, 2018 4:37:36 PM
> 收件人: edk2-devel@lists.01.org
> 抄送: Ruiyu Ni; Jeff Fan; Laszlo Ersek
> 主题: [Patch] UefiCpuPkg/MpInitLib: Optimize get processor number performance.
>
> Current function has low performance because it calls GetApicId
> many times.
>
> New logic first try to base on the stack range used by AP to
> find the processor number. If this solution failed, then call
> GetApicId once and base on this value to search the processor.
>
> Cc: Ruiyu Ni <ruiyu.ni@intel.com>
> Cc: Jeff Fan <vanjeff_919@hotmail.com>
> Cc: Laszlo Ersek <lersek@redhat.com>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Eric Dong <eric.dong@intel.com>
> ---
>  UefiCpuPkg/Library/MpInitLib/MpLib.c | 25 ++++++++++++++++++++++---
>  1 file changed, 22 insertions(+), 3 deletions(-)
>
> diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.c b/UefiCpuPkg/Library/MpInitLib/MpLib.c
> index eb2765910c..abd65bee1a 100644
> --- a/UefiCpuPkg/Library/MpInitLib/MpLib.c
> +++ b/UefiCpuPkg/Library/MpInitLib/MpLib.c
> @@ -418,7 +418,8 @@ ApInitializeSync (
>  }
>
>  /**
> -  Find the current Processor number by APIC ID.
> +  First try to find the current Processor number by stack address,
> +  if it failed, then base on APIC ID.
>
>    @param[in]  CpuMpData         Pointer to PEI CPU MP Data
>    @param[out] ProcessorNumber   Return the pocessor number found
> @@ -435,16 +436,34 @@ GetProcessorNumber (
>    UINTN                   TotalProcessorNumber;
>    UINTN                   Index;
>    CPU_INFO_IN_HOB         *CpuInfoInHob;
> +  UINT32                  CurrentApicId;
>
> +  TotalProcessorNumber = CpuMpData->CpuCount;
>    CpuInfoInHob = (CPU_INFO_IN_HOB *) (UINTN) CpuMpData->CpuInfoInHob;
>
> -  TotalProcessorNumber = CpuMpData->CpuCount;
> +  //
> +  // First try to base on current stack address to find the AP index.
> +  // &TotalProcessorNumber value located in the stack range.
> +  //
>    for (Index = 0; Index < TotalProcessorNumber; Index ++) {
> -    if (CpuInfoInHob[Index].ApicId == GetApicId ()) {
> +    if ((CpuInfoInHob[Index].ApTopOfStack > (UINTN) (&TotalProcessorNumber)) &&
> +        (CpuInfoInHob[Index].ApTopOfStack - CpuMpData->CpuApStackSize < (UINTN) (&TotalProcessorNumber))) {
>        *ProcessorNumber = Index;
>        return EFI_SUCCESS;
>      }
>    }

(1) If I understand correctly, ApTopOfStack is the exclusive end
(highest address) of the AP stack, so any local variable is supposed to
start strictly below it (the stack grows down). This seems to justify
the ">" relational operator, in the first subcondition; OK.

However, what guarantees that the TotalProcessorNumber local variable is
not located exactly at the (inclusive) base of the AP stack? IOW, why is
"<" correct, in the second subcondition, rather than "<="?


(2) I'm generally unhappy about taking the address of local variables,
in order to determine stack location in C language. Instead, I think we
should have AsmReadEsp() / AsmReadRsp() functions -- we used to have
AsmReadSp() for Itanium. Please see the following sub-thread, where
Jordan originally suggested AsmReadEsp() / AsmReadRsp():

http://mid.mail-archive.com/151056410867.15809.659701894226687543@jljusten-skl

http://mid.mail-archive.com/151059627258.20614.16505766191415005802@jljusten-skl

Should I file a Feature Request for BaseLib, about adding AsmReadEsp() /
AsmReadRsp()?

I'm not suggesting that we block this patch with that feature request,
but perhaps we should block the *next* patch.


For the present patch, I'll follow up with test results separately.

Thanks,
Laszlo

> +
> +  //
> +  // If can't base on stack to find the AP index, use the APIC ID.
> +  //
> +  CurrentApicId = GetApicId ();
> +  for (Index = 0; Index < TotalProcessorNumber; Index ++) {
> +    if (CpuInfoInHob[Index].ApicId == CurrentApicId) {
> +      *ProcessorNumber = Index;
> +      return EFI_SUCCESS;
> +    }
> +  }
> +
>    return EFI_NOT_FOUND;
>  }
>
> --
> 2.15.0.windows.1
>
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
>


             reply	other threads:[~2018-07-05 14:00 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-05 14:00 Fan Jeff [this message]
  -- strict thread matches above, loose matches on Subject: below --
2018-07-04  8:37 [Patch] UefiCpuPkg/MpInitLib: Optimize get processor number performance Eric Dong
     [not found] ` <SN6PR19MB22695C13EA19A741F4B1FB88D7410@SN6PR19MB2269.namprd19.prod.outlook.com>
2018-07-05 13:04   ` 答复: " Laszlo Ersek
2018-07-05 13:15     ` Laszlo Ersek
2018-07-09  3:04     ` Dong, Eric
2018-07-09  6:13       ` Dong, Eric
2018-07-09  8:48         ` Laszlo Ersek
2018-07-11  7:45         ` Yao, Jiewen
2018-07-11 11:31           ` Dong, Eric
2018-07-11 15:11             ` Laszlo Ersek
2018-07-12  3:04               ` Dong, Eric
2018-07-18  2:50             ` Dong, Eric
2018-07-09  8:47       ` 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=SN6PR19MB22694930D53F6AD6E8F3EE6FD7400@SN6PR19MB2269.namprd19.prod.outlook.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