Date: Fri, 1 Sep 2006 02:39:32 -0500 (CDT) From: Scott Bennett <bennett@cs.niu.edu> To: backyard1454-bsd@yahoo.com Cc: Jordi Carrillo <jordilin@gmail.com>, freebsd-questions@freebsd.org Subject: Re: SMP detection Message-ID: <200609010739.k817dWGc011315@mp.cs.niu.edu>
next in thread | raw e-mail | index | archive | help
On Thu, 31 Aug 2006 07:05:05 -0700 (PDT) backyard1454-bsd@yahoo.com
wrote:
>--- Skylar Thompson <skylar@cs.earlham.edu> wrote:
>
>> Jordi Carrillo wrote:
>> > 2006/8/30, backyard <backyard1454-bsd@yahoo.com>:
>> >>
>> >>
>> >>
>> >> --- Jordi Carrillo <jordilin@gmail.com> wrote:
>> >>
>> >> > I've read that SMP should be disabled for
>> >> > performance issues (I did not know
>> >> > that before installing freebsd). I have a P4
>> 3GHz
>> >> > with hyperthreading
>> >> > technology. I have the SMP-GENERIC kernel and
>> it
>> >> > only launches one cpu. So,
5.4 made that the default, as has been noted here previously.
See, for example,
http://www.freebsd.org/cgi/getmsg.cgi?fetch=239087+242169+/usr/local/www/db/text/2006/freebsd-questions/20060806.freebsd-questions
(Beware of linewrap in the URL.)
>> >> > I've decided to disable SMP from BIOS. Is that
>> ok?,
Sure, but why? Unless you have a multi-user system whose
users whose skills at cracking systems based upon hardware security
deficiencies, why would you wish to forego roughly 13%-38% of your
P4's processing capacity?
>> >> > knowing that I have a
>> >> > Smp enabled kernel? or should I install one
>> without
>> >> > smp? If so, is there a
The GENERIC kernel is a uniprocessor kernel. The SMP kernel
specifies the SMP option and then simply includes the rest of the
GENERIC configuration. If you're running GENERIC, then the sysctl
variable won't make any difference. If you're running SMP, then
you need to change the variable to 1. (See the above referenced
posting URL.)
>> >> > way to install one already precompiled?
If you didn't build SMP, then you probably are running GENERIC.
IIRC, the system as distributed has only a GENERIC kernel already
built.
>> >> > [stuff deleted --SB]
>> >> >
>> >>
>> >> if you aren't concerned with bad users or hackers
>> >> hitting the box I would just enable HT with the
>> sysctl
>> >> variable. This will not make things run slower at
>> all,
>> >> just (in theory) less secure, which is why the
>> >> veriable was created in the first place as I
>> recall.
>> >> If you are concerned I would wait until you
>> update
>> >> your system and then just build a GENERIC/CUSTOM
>> >> kernel without the SMP option set.
>> >>
>> >>
>> >> -brian
>> >>
>> >
>> >
>> > I will disable smp from bios. If I have a smp
>> kernel, I suppose there
>> > will
>> > be no problem after all. Would that be ok?
>> > The problem with having SMP enabled is that the
>> smp kernel only
>> > detects one
>> > cpu and the system monitor only features one cpu
>> as well as gkrellm (in
>> > Linux it shows two cpus). When compiling the
>> system monitor shows the
>> > cpu at
>> > a maximum of 50%, so what's going on with the
>> other 50%?
>> > writing machdep.hlt_logical_cpus to 2 in
>> loader.conf does not solve
>> > anything.
Why would you expect it to solve anything?
>> I believe FreeBSD uses the other logical CPU to
>> handle hardware
>> interrupts, which can still help performance. You
>> can check dmesg to see
>> how it's actually handling it.
>>
>> --
>> -- Skylar Thompson (skylar@cs.earlham.edu)
>> -- http://www.cs.earlham.edu/~skylar/
>>
>>
>>
>
>While that is one method of hamdling SMP I'm fairly
>certain FreeBSD does not use this model. The problem
>with one CPU handling interrupts and one handling
>processes is if your doing a 9000x9000 element matrix
>inversion to calculate say the wave function for
>uranium (yeah not right, but this be some nasty math
>so bear with me); then even if the math library is
>thread aware, one CPU will be frying eggs, and the
>other one will be twiddling it's thumbs waiting on
>interrupts to process. Most likely an
>ACPI_THERMALZONE...
>
>>From memory on my readings of Implementation of
>FreeBSD 5.4 ( I think thats the title, but the Black
>Book written by the BSD gurus...) It was decided the
>SMP scheduler would handle processes and interrupts
>simultainiously as scheduled and modified with
>affinities to avoid switching which CPU cache has the
>running process. This might be why HT is slower
>because it only has one CPU cache so trying to keep
>things on one core doesn't improve performance at all
>because either core can access the cache. Since HT was
>not the brightest thing Intel could have done (kind of
>like 20-bit addressing...) and since AMD has Dual
>cores they need to compete with I don't think tweaking
>scheduler code to remove affinities on HT would be in
>the works. I don't even know if that would help
>either, just thinking out loud.
Processor groups were invented to deal with HT-enabled
CPUs. Processors in the same group are understood to have
essentially no cost involved in moving a thread from one
logical processor to another, whereas the traditional costs
of moving a thread from one real CPU to another are still
accounted for by affinity to the processor group. How the
concept and implementation of processor groups with change
now that multi-cored chips exist I do not know. Moving a
thread among multiple cores on the same chip incurs some
costs, unlike the HT case, yet that cost is different,
perhaps *greater*, than the cost of moving a thread to a
separate chip. Consider that the current dual-cored chips
have separate caches and TLBs, so in that respect, the cost
of moving a thread between cores is similar to moving a
thread between chips. However, the two cores *share* some
resources, such as bandwidth to/from the world outside the
chip, whereas two separate chips may have a certain degree
of parallel access (e.g., signalling other chips or cards,
data transmission to/from cards) depending upon which
busses are accessed, in which case there would be some
actual benefit (cost reduction) in moving a thread to a
different chip rather than to another core in the same chip.
>
>But Interrupts are handled by both CPUs once the
>additional CPUs are launched by the boot CPU via the
>kernel. The scheduler is designed to keep all the
>pipes in the plant running with process/interuppts.
>
>-brian
>
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 *
**********************************************************************
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200609010739.k817dWGc011315>