Re: SMP detection
On Thu, 31 Aug 2006 07:05:05 -0700 (PDT) [EMAIL PROTECTED] wrote: --- Skylar Thompson [EMAIL PROTECTED] wrote: Jordi Carrillo wrote: 2006/8/30, backyard [EMAIL PROTECTED]: --- Jordi Carrillo [EMAIL PROTECTED] 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 ([EMAIL PROTECTED]) -- 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
Re: shared cache -- Re: SMP detection
On Thu, 31 Aug 2006 08:18:57 -0700 (PDT) backyard [EMAIL PROTECTED] wrote: --- Chad Leigh -- Shire.Net LLC [EMAIL PROTECTED] wrote: On Aug 30, 2006, at 12:12 PM, backyard wrote: 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. How is this any different than say an Intel Core Duo or Core 2 Duo? I believe they have a shared cache as well for each (real) processor core. I'm not sure about the Core Duo, but I think it has two separate, fixed-sized caches. The Core 2 Duo supposedly keeps a total of 4 MB of L2 cache, but dynamically manages how much is currently used by each core, still keeping what they use separate (i.e., each core can only access what is allocated to it). Chad --- Chad Leigh -- Shire.Net LLC Your Web App and Email hosting provider chad at shire.net I would say there is no difference if what you say is true. A Multi-Core chip is only true SMP if the two cores share no resources internally and thus are capable of running process separate from each other entirely. independantly and with their own internal caches. The process shouldn't have to wait on a lock to access it's cache, which I would have to assume occurs on these HT machines; which is probably why they have degraded performance. The cache should only be shared if a process explicity copies its content to the other cores cache. If should not be possible for both Cores to see the same internal cache. To my Thus far, Intel's dual-cored processors do not have HT enabled, though the circuitry may well be present. Intel has said publicly that they may make HT available again at some point, so that each core would have two logical processors. If Intel does that, then presumably the FreeBSD kernel would need a third level of processor relationships in addition to the distinction between processors in the same group (i.e., logical processors in a particular real processor) versus processors in different groups (i.e., logical processors in different real processors). knowledge the AMDx2 follow this model with independant cores only sharing a common die. This ensures the context and priveledge of one running process cannot be compromised by a non-priveldeged process waiting on say a login attempt to root, and then grabbing the password from the common cache before the privelidged process can clean up. Many people have panned HT, but HT does make it possible to keep more components of a real processor (e.g., DAT, TLB, FPU, address and data lines to the off- chip world, etc.) in active use more of the time. This is an issue that is separate from the issues involving multiple real processors on one die. It is, of course, too bad that Intel's design allows the logical processors to cross-access their cache spaces, but I doubt that that particular weakness has hurt anyone much. A greater problem for some installations is the accounting problem caused by the fact that a logical processor waiting for a hardware lock set by another logical processor in the same core appears to have 100% CPU utilization during the lockout. In other words, 100% utilization of both logical processors is equivalent to something on the order of 110% - 140% utilization of a single logical processor that has no competition from another logical processor. So which thread is getting overcharged? The software cannot determine the answer. And what institutional accounting policy should be in effect to handle billing for CPU time in an HT-enabled environment, given this indeterminacy? I don't think this flaw has been exploited yet, but the boys at OpenBSD found it (from memory, pretty sure it was one of them) and it has spread through the BSD community as it has potentially dire consequences. Personally I'm done with Intel so I don't think I'll ever have this issue. Afterall they're still the reason my computer boots up with 640k of RAM... I also think AMD has come from being a clone to being on top of the market, but this is my personal opinion. The fact Core Duos are only 32-bit means Intel is still only concerned with shortend gains on the Windows market, not long term migration to 64-bit PCs like That's not quite entirely true. According to the Intel web site, some models of Core chips don't list EM64T as a supported feature, but some of the *do*. The Core Solo and Core Duo series do not show EM64T as a feature, but the entire Mobile Core 2 Duo series, the Core 2 Extreme X6800, and the entire Core 2 Duo Desktop series do list EM64T as a supported feature. everyone else... And banking on Microsoft has never been a solid idea; its too bad banks use Windows; there's a security nightmare, but a topic in and of itself...
Re: SMP detection
--- Jordi Carrillo [EMAIL PROTECTED] wrote: 2006/8/31, Skylar Thompson [EMAIL PROTECTED]: Michal Mertl wrote: 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). Could you clarify note 20031022 in /usr/src/UPDATING? It states that HTT CPUs are used for interrupts if they are detected, even if they aren't used by regular processes. Was this something that just showed up in pre-6.x releases? -- -- Skylar Thompson ([EMAIL PROTECTED]) -- http://www.cs.earlham.edu/~skylar/ Another question that's wondering me is why FreeBSD with the SMP kernel the gnome system monitor (Applications-System Tools-System Monitor) only shows one CPU when Linux with a SMP kernel shows two CPUs -- http://jordilin.wordpress.com I'm assuming you talking about an HT SMP scenario... Linux is running the second core, but *BSD will not unless you tell it too. I'll check with my dually once I get home but I'm fairly certain even if your running an SMP kernel if the other CPU isn't used, it isn't going to tell you what processes are running on it, because nothing is scheduled to run on it. Linux doesn't care about the possible exploits and so by default runs both HT cores. Look at it like this I have two hands, I could put two P99C-ASs in them, but if only one has a magazine in it why and I going to claim I got two pieces??? Basically by not setting the ...hyperthreading_allowed... variable you have removed the magazine from one of your cores... But I will check because I seem to recall there being some kind of issue like this with my 5.4 box that I just kind of shrugged off at the time. I thought it was with KDE not gnome though... It should show both or all your cores and what is running. But it can't show you what is running on a CPU the kernel has disavowed. -brian ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SMP detection
2006/8/31, Skylar Thompson [EMAIL PROTECTED]: Michal Mertl wrote: 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). Could you clarify note 20031022 in /usr/src/UPDATING? It states that HTT CPUs are used for interrupts if they are detected, even if they aren't used by regular processes. Was this something that just showed up in pre-6.x releases? -- -- Skylar Thompson ([EMAIL PROTECTED]) -- http://www.cs.earlham.edu/~skylar/ Another question that's wondering me is why FreeBSD with the SMP kernel the gnome system monitor (Applications-System Tools-System Monitor) only shows one CPU when Linux with a SMP kernel shows two CPUs -- http://jordilin.wordpress.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SMP detection
Skylar Thompson wrote: Michal Mertl wrote: 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). Could you clarify note 20031022 in /usr/src/UPDATING? It states that HTT CPUs are used for interrupts if they are detected, even if they aren't used by regular processes. Was this something that just showed up in pre-6.x releases? I think it means that if an interrupt would for some reason be signalled to the unused logical core it wouldn't be lost or something. Michal ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SMP detection
--- Skylar Thompson [EMAIL PROTECTED] wrote: Jordi Carrillo wrote: 2006/8/30, backyard [EMAIL PROTECTED]: --- Jordi Carrillo [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 performance. You can check dmesg to see how it's actually handling it. -- -- Skylar Thompson ([EMAIL PROTECTED]) -- 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. 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 ___ freebsd-questions@freebsd.org mailing list
Re: SMP detection
--- Michal Mertl [EMAIL PROTECTED] wrote: Skylar Thompson wrote: Jordi Carrillo wrote: 2006/8/30, backyard [EMAIL PROTECTED]: --- Jordi Carrillo [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 ___ freebsd-questions@freebsd.org mailing list
Re: shared cache -- Re: SMP detection
--- Chad Leigh -- Shire.Net LLC [EMAIL PROTECTED] wrote: On Aug 30, 2006, at 12:12 PM, backyard wrote: 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. How is this any different than say an Intel Core Duo or Core 2 Duo? I believe they have a shared cache as well for each (real) processor core. Chad --- Chad Leigh -- Shire.Net LLC Your Web App and Email hosting provider chad at shire.net I would say there is no difference if what you say is true. A Multi-Core chip is only true SMP if the two cores share no resources internally and thus are capable of running process separate from each other entirely. independantly and with their own internal caches. The process shouldn't have to wait on a lock to access it's cache, which I would have to assume occurs on these HT machines; which is probably why they have degraded performance. The cache should only be shared if a process explicity copies its content to the other cores cache. If should not be possible for both Cores to see the same internal cache. To my knowledge the AMDx2 follow this model with independant cores only sharing a common die. This ensures the context and priveledge of one running process cannot be compromised by a non-priveldeged process waiting on say a login attempt to root, and then grabbing the password from the common cache before the privelidged process can clean up. I don't think this flaw has been exploited yet, but the boys at OpenBSD found it (from memory, pretty sure it was one of them) and it has spread through the BSD community as it has potentially dire consequences. Personally I'm done with Intel so I don't think I'll ever have this issue. Afterall they're still the reason my computer boots up with 640k of RAM... I also think AMD has come from being a clone to being on top of the market, but this is my personal opinion. The fact Core Duos are only 32-bit means Intel is still only concerned with shortend gains on the Windows market, not long term migration to 64-bit PCs like everyone else... And banking on Microsoft has never been a solid idea; its too bad banks use Windows; there's a security nightmare, but a topic in and of itself... -brian ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: shared cache -- Re: SMP detection
Core 2 Duos have the EM64T extensions. Core Duos (Yonah) are a mobile chip only, not a full line of processors like the Core 2 architecture (Merom, Conroe, Woodcrest). I suspect the Core 2 chips do not suffer from the same security implications as HT-enabled processors. I'm not certain, but I think each processor has access to half the cache so the only reason it's shared is that it's on the same die and both cores are using parts of it. Josh The fact Core Duos are only 32-bit means Intel is still only concerned with shortend gains on the Windows market, not long term migration to 64-bit PCs like everyone else... And banking on Microsoft has never been a solid idea; its too bad banks use Windows; there's a security nightmare, but a topic in and of itself... -brian ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SMP detection
backyard píše v čt 31. 08. 2006 v 07:45 -0700: --- Michal Mertl [EMAIL PROTECTED] wrote: Skylar Thompson wrote: Jordi Carrillo wrote: 2006/8/30, backyard [EMAIL PROTECTED]: --- Jordi Carrillo [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
Re: SMP detection
2006/8/31, backyard [EMAIL PROTECTED]: --- Michal Mertl [EMAIL PROTECTED] wrote: Skylar Thompson wrote: Jordi Carrillo wrote: 2006/8/30, backyard [EMAIL PROTECTED]: --- Jordi Carrillo [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
Re: SMP detection
--- Jordi Carrillo [EMAIL PROTECTED] wrote: 2006/8/31, backyard [EMAIL PROTECTED]: --- Michal Mertl [EMAIL PROTECTED] wrote: Skylar Thompson wrote: Jordi Carrillo wrote: 2006/8/30, backyard [EMAIL PROTECTED]: --- Jordi Carrillo [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
Re: SMP detection
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 I believe that HTT was disabled in FreeBSD per security report FreeBSD-SA-05:09.htt (http://security.freebsd.org/advisories/FreeBSD-SA-05:09.htt.asc). If you want to enable, I believe you can set the loader.conf option machdep.hlt_logical_cpus to 2. Having SMP enabled on a uniprocessor box shouldn't give you any stability problems, but SMP does use a different locking mechanism that can affect performance. You will probably get slightly better performance if you run with an SMP-disabled kernel. -- -- Skylar Thompson ([EMAIL PROTECTED]) -- http://www.cs.earlham.edu/~skylar/ signature.asc Description: OpenPGP digital signature
Re: SMP detection
On Wednesday 30 August 2006 20:20, 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 Try here: http://www.bsdforums.org/forums/showthread.php?t=152goto=nextnewest Good luck! -- Best regards, Simon Phoenix (Phoenix Lab.) --- KeyID: 0x2569D30B Fingerprint: 78FC 5C40 07CC D331 148E CC79 84B8 D514 2569 D30B --- pgpawwtJTiIXM.pgp Description: PGP signature
Re: SMP detection
--- Jordi Carrillo [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SMP detection
2006/8/30, backyard [EMAIL PROTECTED]: --- Jordi Carrillo [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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. -- http://jordilin.wordpress.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SMP detection
Jordi Carrillo wrote: 2006/8/30, backyard [EMAIL PROTECTED]: --- Jordi Carrillo [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 performance. You can check dmesg to see how it's actually handling it. -- -- Skylar Thompson ([EMAIL PROTECTED]) -- http://www.cs.earlham.edu/~skylar/ signature.asc Description: OpenPGP digital signature
Re: SMP detection
Skylar, So, 50% is used for processes and the other 50% to handle hardware interrupts. Is that right? 2006/8/30, Skylar Thompson [EMAIL PROTECTED]: Jordi Carrillo wrote: 2006/8/30, backyard [EMAIL PROTECTED]: --- Jordi Carrillo [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 performance. You can check dmesg to see how it's actually handling it. -- -- Skylar Thompson ([EMAIL PROTECTED]) -- http://www.cs.earlham.edu/~skylar/ -- http://jordilin.wordpress.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
shared cache -- Re: SMP detection
On Aug 30, 2006, at 12:12 PM, backyard wrote: 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. How is this any different than say an Intel Core Duo or Core 2 Duo? I believe they have a shared cache as well for each (real) processor core. Chad --- Chad Leigh -- Shire.Net LLC Your Web App and Email hosting provider chad at shire.net ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SMP detection
Jordi Carrillo wrote: Skylar, So, 50% is used for processes and the other 50% to handle hardware interrupts. Is that right? I believe so, but the blurb that I read that in is from 2003. There's a good chance someone will jump in to correct me. :) It was in /usr/src/UPDATING: 20031022: Support for HyperThread logical CPUs has now been enabled by default. As a result, the HTT kernel option no longer exists. Instead, the logical CPUs are always started so that they can handle interrupts. However, the extra logical CPUs are prevented from executing user processes by default. To enable the logical CPUs, change the value of the machdep.hlt_logical_cpus from 1 to 0. This value can also be set from the loader as a tunable of the same name. -- -- Skylar Thompson ([EMAIL PROTECTED]) -- http://www.cs.earlham.edu/~skylar/ signature.asc Description: OpenPGP digital signature
Re: SMP detection
--- Jordi Carrillo [EMAIL PROTECTED] wrote: 2006/8/30, backyard [EMAIL PROTECTED]: --- Jordi Carrillo [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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. -- machdep.hyperthreading_allowed=1 in loader.conf from my reading on the web... is the variable you should probably be setting, the other variable will disable cpu's on the system or limit how many are used. It does not turn on HT. Linux does not have an option like this to disable HT, I believe it must be passed to the kernel at boot and I don't know what the exact switch is but the Linux community is not as concerned with the potential exploit as the *BSD community is and so they let HTs run under their SMP kernel. 50% is running idle, this is pretty normal, At least on the systems I've seen when it is building the system. You have to remember most of compiling is reading code and libraries then putting it together and back on the hard drive. Compiling is I/O intensive more then CPU intensive. If you set MAKEOPTS=-j5 in make.conf you will compile quicker use more cpu power, but it will maybe spike around 80%. usually this is set by 2X CPU_CORES +1 but it makes my dual p3 550Mhz Xeon build a system with the quickness... You maybe able to get away with -j9 as my little formula might be based on Linux more then BSD and I know generally BSD allows for more make processes to be going at once. maybe 4x CPU_CORE +1 is more in order. Experiment until your loaded as high as you want to, but its nice to have Gnome/KDE going while you're building a system and watching a movie; so having 50% to play with isn't a bad thing... -brian ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SMP detection
Skylar Thompson wrote: Jordi Carrillo wrote: 2006/8/30, backyard [EMAIL PROTECTED]: --- Jordi Carrillo [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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. As far as know - trying to use HTT normally hurts performance and only a very special load on a machine can show increase in overall performance. Newer Intel CPUs have better HTT (probably meaning less sharing of stuff among the HTT cores - towards current trend - multi-core) and there they say it performs quite good with real world load to handle the logical cores as separate CPUs. Of course (if you built purpose built appliance) you can squeeze more from the HW when you exactly know what you need to do - you have some task(s) which do the data analysis and kernel threads which do the interrupt processing/data shifting) - than effectively using HTT might be possible (I have never heard of anyone effectively using HTT). Newest Intel CPUs don't bother with HTT - they are multicore - close to nothing is shared among (logical) CPUs. You would see each of these CPUs as a CPU in FreeBSD and they will get scheduled tasks to finish. Michal
Re: SMP detection
Michal Mertl wrote: 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). Could you clarify note 20031022 in /usr/src/UPDATING? It states that HTT CPUs are used for interrupts if they are detected, even if they aren't used by regular processes. Was this something that just showed up in pre-6.x releases? -- -- Skylar Thompson ([EMAIL PROTECTED]) -- http://www.cs.earlham.edu/~skylar/ signature.asc Description: OpenPGP digital signature
