Re: [PATCH 2/5] MdePkg: Allow PcdFSBClock to by Dynamic

["Anthony PERARD" <anthony.perard@citrix.com>]

On Mon, Feb 03, 2020 at 03:34:07PM +0000, Anthony PERARD wrote:
> On Mon, Feb 03, 2020 at 01:34:55AM +0000, Gao, Liming wrote:
> > Anthony:
> >   This change is OK to me. But if this PCD is configured as Dynamic, its value will be got from PCD service. This operation will take some time and cause the inaccurate time delay. Have you measured its impact?
> 
> No, I haven't. But I don't think it matter in a Xen guest, the APIC timer is
> emulated anyway, so reading from a register of the APIC is going to be
> slower than getting the value from the PCD services, I think.
> (Hopefully, I'm not too wrong.)
> 
> But I'll give it at measuring the difference, it would be interesting to
> know.

Now that I've given a try, having the value as Dynamic doesn't change
anything in a Xen guest.

On my test machine, simply running GetPerformanceCounter (); takes
between 10000 ns and 20000 ns. Reading the dynamic value from PCD on the
other hand takes about 350ns. (10ns if it's static.)

When I run NanoSecondDelay() with different values, I have:
  - with static pcd:
           63894 ns to delay by 1 ns
           66611 ns to delay by 10 ns
           43927 ns to delay by 100 ns
           71367 ns to delay by 1000 ns
           55881 ns to delay by 10000 ns
          147716 ns to delay by 100000 ns
         1048335 ns to delay by 1000000 ns
        10041179 ns to delay by 10000000 ns
  - with a dynamic pcd:
           40949 ns to delay by 1 ns
           84832 ns to delay by 10 ns
           82745 ns to delay by 100 ns
           59848 ns to delay by 1000 ns
           52647 ns to delay by 10000 ns
          137051 ns to delay by 100000 ns
         1042492 ns to delay by 1000000 ns
        10036306 ns to delay by 10000000 ns

So, the kind of PCD used for PcdFSBClock on Xen (with OvmfXen) doesn't
really matter.

Anyway, thanks for the feedback.

-- 
Anthony PERARD