SMP detection

[backyard]

--- Michal Mertl <mime at traveller.cz> wrote:

> Skylar Thompson wrote:
> > Jordi Carrillo wrote:
> > > 2006/8/30, backyard
> <backyard1454-bsd at yahoo.com>:
> > >>
> > >>
> > >>
> > >> --- Jordi Carrillo <jordilin at 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,
> > >> > I've decided to disable SMP from BIOS. Is
> that ok?,
> > >> > knowing that I have a
> > >> > Smp enabled kernel? or should I install one
> without
> > >> > smp? If so, is there a
> > >> > way to install one already precompiled?
> > >> > Thanks in advance
> > >> >
> > >> > --
> > >> > http://jordilin.wordpress.com
> > >> >
> _______________________________________________
> > >> > freebsd-questions at freebsd.org mailing list
> > >> >
> > >>
>
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> > >> > To unsubscribe, send any mail to
> > >> > "freebsd-questions-unsubscribe at freebsd.org"
> > >> >
> > >>
> > >> if the system runs with one cpu now and you
> don't
> > >> enable smp with HT with the sysctl variable
> then you
> > >> should be ok. If your not doing SMP then
> recompiling
> > >> the kernel for single processor mode will make
> things
> > >> run a little quicker because the SMP code won't
> come
> > >> into play.
> > >>
> > >> with HT disabling in FreeBSD is more for the
> security
> > >> issues about a potential exploit whereby one
> process
> > >> in one pipe can access the priveledged
> information of
> > >> a process in another pipe because the two cores
> share
> > >> one processor cache and thus one cache table.
> To my
> > >> knowledge this hasn't been exploited yet.
> > >>
> > >> If you just install the generic kernel you it
> should
> > >> be only the uniprocessor one. I would just do
> a:
> > >>
> > >> cd /usr/src && make buildworld && make
> > >> KERNCONF=GENERIC buildkernel && make
> KERNCONF=GENERIC
> > >> installkernel
> > >>
> > >> as opposed to a binary version assuming you
> haven't
> > >> updated yet you won't have to install world but
> I
> > >> believe it must have the build in the source
> tree to
> > >> build a kernel. On your P4 though the
> difference
> > >> between SMP and uniproc may not be worth the
> trouble
> > >> because I don't think much of a gain would be
> made. on
> > >> a P1 a much different story...
> > >>
> > >> 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.
> 
> > I believe FreeBSD uses the other logical CPU to
> handle hardware
> > interrupts, which can still help perormance. You
> can check dmesg to see
> > how it's actually handling it.
> 
> No! Kernel threads (e.g. handling interrupts) aren't
> that much different
> to normal processes.
> 
> Logical CPUs on a single HTT capable CPU share most
> of the CPU logic,
> especially all the external stuff (handling
> interrupts). Scheduling
> handling of interrupts on the "secondary/logical"
> core  wouldn't
> probably help performance at all (if that is at all
> possible).
> 
> When FreeBSD sees logical CPUs it means HTT is
> either enabled in BIOS or
> that disabling HTT in BIOS does not hide the CPUs to
> FreeBSD (bug in
> BIOS/FreeBSD).
> 
> Until you enable scheduler to schedule tasks to HTT
> cores (with
> machdep.hyperthreading_allowed=1 in loader.conf)
> (disabled by default
> due to mentioned security/performance reasons)
> machine won't utilize the
> logical HTT CPUs. Therefore total CPU utilization
> won't be more than
> 50%, because there are the (unused) logical CPUs
> which don't get
> scheduled tasks.
> 

are you sure about this???
I would have figured the scheduler wouldn't see the
other core at all without this option set and so it
wouldn't be used in calculating load at all. 50% on a
compile is fairly normal from my experience. I don't
have too much experience with HT as I always opt for
true SMP so I can't speak with authority on the
matter.

but if 

top

isn't showing CPU 1 or 0 next to a process then it
isn't computing the load on multiple cores... Also if 

dmesg |grep cpu

doesn't show application cpu1 (and on through all your
cores)... launched then the system isn't looking at
the HT core at all.


-brian