From owner-freebsd-questions@FreeBSD.ORG Thu Aug 31 14:45:23 2006 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F1EF916A4E1 for ; Thu, 31 Aug 2006 14:45:23 +0000 (UTC) (envelope-from backyard1454-bsd@yahoo.com) Received: from web83112.mail.mud.yahoo.com (web83112.mail.mud.yahoo.com [216.252.101.41]) by mx1.FreeBSD.org (Postfix) with SMTP id 3779843D5C for ; Thu, 31 Aug 2006 14:45:22 +0000 (GMT) (envelope-from backyard1454-bsd@yahoo.com) Received: (qmail 59434 invoked by uid 60001); 31 Aug 2006 14:45:21 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=MNNqjtoQkzvvyLogDr19poB9QVRQl1LHrk5KaklAm6+9YbEaKBl8J3BOcLebMjt8//8PKv2Yc00gC1EUnZ0fppa5jYvmp8MksFVSwi5SvEGGaq9qqfG8CYStDOyYlyErttdJWuPpDbg/KUJqJvRP7HMcW7mqXDBirKweKcps4V0= ; Message-ID: <20060831144521.59432.qmail@web83112.mail.mud.yahoo.com> Received: from [63.240.228.37] by web83112.mail.mud.yahoo.com via HTTP; Thu, 31 Aug 2006 07:45:21 PDT Date: Thu, 31 Aug 2006 07:45:21 -0700 (PDT) From: backyard To: Michal Mertl , skylar@cs.earlham.edu In-Reply-To: <1156982800.1017.37.camel@genius.i.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: backyard1454-bsd@yahoo.com, Jordi Carrillo , freebsd-questions@freebsd.org Subject: Re: SMP detection X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: backyard1454-bsd@yahoo.com List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2006 14:45:24 -0000 --- Michal Mertl wrote: > Skylar Thompson wrote: > > Jordi Carrillo wrote: > > > 2006/8/30, backyard > : > > >> > > >> > > >> > > >> --- Jordi Carrillo 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@freebsd.org mailing list > > >> > > > >> > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > > >> > To unsubscribe, send any mail to > > >> > "freebsd-questions-unsubscribe@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