On Thu, 13 Jan 2005 02:11:27 +0100 Anthony Atkielski
<[EMAIL PROTECTED]> wrote:
>Scott Bennett writes:
>
>SB> I notice that the 5.2.1 boot messages refer to the second core as an
>SB> AP, which I'm guessing stands for "attached processor". If that
>SB> guess is correct, then it means that only the first core is able to
>SB> perform certain functions, and the AP core has to get the first core
>SB> to do those things for it when it needs them done.
>
>AP just stands for "application processor," from what I've seen. My
>impression from snooping in the code and looking elsewhere is that an AP
>is just a processor that is halted during system boot. The processor
>that executes the boot sequence is the bootstrap processor (BSP). Once
>the boot proceeds far enough to allow synchronization of multiple
>processors, the other processors (APs all) are started by the BSP.
Oh, good. That sounds much better than what I was thinking.
>
>This doesn't necessarily mean that the BSP is special in any other way
>outside of startup or shutdown, and hopefully it is not, as that would
>defeat much of the conceptual purpose behind SMP. I know that on
>operating systems that insist on keeping one processor special for
>certain tasks, the speed of this processor often becomes a bottleneck on
>heavily loaded systems, as it tops out trying to handle all the
>"restricted" stuff for the other processors and itself.
Usually that sort of restriction has a basis in hardware. For example,
IBM's MP mainframes *used to* require that the same processor that started
an I/O operation be the one that fielded the interrupt(s) upon completion
of the operation. Some machines also had the main processor/attached
processor configuration, in which the attached processor had no access to
the I/O hardware at all, so all I/O handling had to be done by the main
processor because the AP had no way to do it.
>
>SB> What Intel claims is essentially that the HT-enabled CPUs allow
>SB> snappier responses in interactive processes when a CPU-bound process
>SB> is running.
>
>That I can believe. One of the great advantages to a multiple-processor
>system is that it's much less likely to bog down if a process decides to
>hog a processor (unless the process runs multiple threads). I think MP
>is more interesting for its ability to run completely independent
>processes or threads than it is for its ability to run multiple
>threads doing the same thing. Few applications require multiple
>high-speed processors churning through code all at once.
>
My main interest in such things at present is for dividing the workload
in fluid dynamics and, most especially, geophysical fluid dynamics models.
Those, of course, do immense amounts of number-crunching with occasional,
massive bouts of I/O. I want to play around with making a two-threaded
version of a GFD model (either atmospheric or oceanic) to see what, if any,
savings there may be in elapsed time by running on both cores vs. just one.
Such a model would have both threads doing essentially the same things,
though operating upon different parts of the arrays involved.
But first, I still have to get a usable FreeBSD system going. :-(
Scott Bennett, Comm. ASMELG, CFIAG
**********************************************************************
* Internet: bennett at cs.niu.edu *
*--------------------------------------------------------------------*
* "A well regulated and disciplined militia, is at all times a good *
* objection to the introduction of that bane of all free governments *
* -- a standing army." *
* -- Gov. John Hancock, New York Journal, 28 January 1790 *
**********************************************************************
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
