SMP detection

backyard backyard1454-bsd at yahoo.com
Thu Aug 31 23:27:07 UTC 2006



--- Jordi Carrillo <jordilin at gmail.com> wrote:

> 2006/8/31, backyard <backyard1454-bsd at yahoo.com>:
> >
> > --- 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
> >
> 
> When you do a "top" in the column marked as "C"
> should put a 1 or 0 in each
> process depending on the cpu the process is being
> executed. Well, top does
> so, only if you write the line
> machdep.hyperthreading_allowed=1 in your
> loader.conf. So, anyone having a pentium with
> hyperthreading, when you
> install freebsd it will install the SMP-GENERIC
> kernel (my case) and then
> you must enable it by writing
> machdep.hyperthreading_allowed=1. If you don't
> then the other cpu is not taken into account (at
> least when you do a top
> only appear 0s in every process, and no 1s). Is my
> explanation correct?
> 
> 
> -- 
> 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"
> 


sounds like it to me. except by what you mean by
"taken in to account" top is only reading internal
scheduler information so it will display 1 and 0 or 3
4 5 6 however many cores/cpus you have that make
things up. I  just don't want to mislead or
misunderstand the 

machdep.hyperthreading_allowed=1 

variable tells an SMP Kernel to allow the scheduler to
send task to the second core. Thus allowing SMP
execution of processes and interrupts. I know I am
likely abriviating what acutally internally occurs.

this does not affect top other then top will read the
schedule tasks and if processes are on the second core
it will report C=1.

But your a lucky dog it always seems I have to rebuild
the installed kernel to enable SMP with my systems.
Very frustrating, but forces me to immediately update
the tree. The point is the above variable is in the
BSD world and must be set if you want HT to work.
Linux does things their own way, which is why I'm
nuking my Gentoo partition this weekend; way too much
chaos for me.

-brian


More information about the freebsd-questions mailing list