On 09/11/2014 07:00 PM, Jordan Justen wrote: > On Thu, Sep 11, 2014 at 12:36 AM, Fan, Jeff <[email protected]> wrote: >> I added my comments in [Jeff]. > > I think quoting works better. Oh well... > >> -----Original Message----- >> From: Jordan Justen [mailto:[email protected]] >> Sent: Thursday, September 11, 2014 3:21 PM >> To: Fan, Jeff >> Cc: Chen Fan; [email protected] >> Subject: Re: [RFC v2 00/15] Introduce Mp Service protocol to UefiCpuPkg >> >> On Wed, Sep 10, 2014 at 11:56 PM, Fan, Jeff <[email protected]> wrote: >>> Why did you get rid of sending IPI to wake up APs? Do you encounter any >>> issue with it? >>> From your patch, I don't know why StarupThisAP () cannot work correctly. >>> Could you send me your AP routine test code and test procedure? >> >> I think that a startup IPI is used once, but not again after the APs have >> been woken once. At least, that was my feedback previously. >> [Jeff] We observed that polling a semaphore in memory for all APs may lead >> the bad boot performance on real platform. So, normally we place APs in one >> hlt-loop and sending start IPI to wake up them. >> Sure, semaphore is also one of our methods to wake up AP. > > This is good information. I only asked Chen to start this way because > it should be simpler for the first pass implementation.
I haven't looked at your code, but here's one item to be careful of on real platforms: MTRRs are disabled on reset, so when APs start up the first time, they are running uncached. This makes them slow until the MTRRs are programmed. It also changes the way the hardware handles semaphores: any uncached semaphore operation requires a bus lock operation, which (on modern CPUs) requires the hardware to halt all the CPUs, let one transaction out to memory, then restart all the CPUs. Needless to say, this doesn't scale.... So try very hard to avoid any sort of semaphore or atomic operation from the APs until the MTRRs are programmed. > I figured a restart process might need to be added to cover a case of > an AP that gets stuck. > > Do you think we should try for an implementation that restarts the APs > each time in the first pass implementation? > > Thanks, > > -Jordan > > ------------------------------------------------------------------------------ > Want excitement? > Manually upgrade your production database. > When you want reliability, choose Perforce > Perforce version control. Predictably reliable. > http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk > _______________________________________________ > edk2-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/edk2-devel > -- Brian -------------------------------------------------------------------- "I have discovered that all human evil comes from this, man's being unable to sit still in a room." -- Blaise Pascal ------------------------------------------------------------------------------ Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk _______________________________________________ edk2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-devel
