SMP detection

[Michal Mertl]

backyard píše v čt 31. 08. 2006 v 07:45 -0700:
> --- 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???

Almost sure but can't check at the moment. I believe there were problems
when all HTT CPUs weren't launched sometimes (when HTT wasn't disabled
with BIOS), so the logical CPU cores are started and fully visible but
only run the idle kernel thread (are 100% idle).

> 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
>