Bruce Evans wrote:
On Tue, 26 Aug 2003, John Baldwin wrote:
On 26-Aug-2003 Yamada Ken Takeshi wrote:
[...]
One test is not sufficient. -current is also not the best
place to test. :) When I first implemented HTT in -current
The above times seem slow enough to be partly the result of
debugging
On Tue, 26 Aug 2003, John Baldwin wrote:
> On 26-Aug-2003 Yamada Ken Takeshi wrote:
> > JYI,
> > I tested machdep.hlt_logical_cpus=0/1, buildworld,
> > and found no particular reason to disable HTT
> > as below with Zeon 2.8Ghz x 2, 1GBmem, Slow IDE HDD.
> >
> > It may not be the common case,
On 26-Aug-2003 Yamada Ken Takeshi wrote:
> JYI,
> I tested machdep.hlt_logical_cpus=0/1, buildworld,
> and found no particular reason to disable HTT
> as below with Zeon 2.8Ghz x 2, 1GBmem, Slow IDE HDD.
>
> It may not be the common case, so just for your info.
>
># sysctl machdep.hlt_log
JYI,
I tested machdep.hlt_logical_cpus=0/1, buildworld,
and found no particular reason to disable HTT
as below with Zeon 2.8Ghz x 2, 1GBmem, Slow IDE HDD.
It may not be the common case, so just for your info.
# sysctl machdep.hlt_logical_cpus=0
# /usr/bin/time make -j32 buildworld
191
On 23-Aug-2003 [EMAIL PROTECTED] wrote:
>> On Fri, Aug 22, 2003 at 07:03:03PM -0400, [EMAIL PROTECTED] wrote:
>>> > That is not an SMP kernel. An SMP kernel (with APIC_IO) would not
>>> print
>>> > out
>>> > the pcib0 interrupt routing messages.
>>> >
>>> > --
>>>
>>> So whats the problem here?
>
On Mon, Aug 25, 2003 at 02:14:18PM -0300, Daniel C. Sobral wrote:
> >I've heard this several times and don't doubt it, but it would be nice to
> >know more about the issue. What type of cases? What benchmarks have
> >been run showing this?
>
> Well, I haven't actually seen any case where there w
Garrett Wollman wrote:
The problem is that the P4 is not very wide to begin with, and it's very
hard to optimize well for that 23-stage pipeline.
I'll say. I spent months tuning some assembly code for P3 and P4
and was quite disappointed that the P4 consistently required
more CPU cycles for the sa
< said:
> There are two problems with HTT. First, L1/L2 cache issues. Second, the
> virtual CPUs are not independent, and there are many cases where
> instructions in one virtual CPU stall the other. So take, for example,
> the case of a userland application on CPU0 stalling the kernel on CPU1.
David O'Brien wrote:
On Mon, Aug 25, 2003 at 08:27:46AM -0600, Scott Long wrote:
Since HTT can lead to performance degradation in some (many?) cases,
the second logical CPU's are halted by default. They are enabled,
however, in order for interrupt routing to work right. Work is ongoing
to make a
On Mon, Aug 25, 2003 at 08:27:46AM -0600, Scott Long wrote:
> Since HTT can lead to performance degradation in some (many?) cases,
> the second logical CPU's are halted by default. They are enabled,
> however, in order for interrupt routing to work right. Work is ongoing
> to make an HTT-aware sc
, August 24, 2003 12:49 PM
To: Kris Kennaway
Cc: Yamada Ken Takeshi; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: HTT on current
yes:
ganymede# grep SMP /usr/src/sys/i386/conf/kernel
options SMP # Symmetric MultiProcessor Kernel
and:
CPU: Intel(R) Pentium(
ROTECTED]; [EMAIL PROTECTED]
Subject: Re: HTT on current
yes:
ganymede# grep SMP /usr/src/sys/i386/conf/kernel
options SMP # Symmetric MultiProcessor Kernel
and:
CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz (2393.19-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0
PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: HTT on current
>
>
>
> yes:
>
> ganymede# grep SMP /usr/src/sys/i386/conf/kernel
> options SMP # Symmetric MultiProcessor Kernel
>
> and:
>
> CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz (2393.19-MHz
> -Original Message-
> From: Sang Woo Shim [mailto:[EMAIL PROTECTED]
> Sent: Saturday, August 23, 2003 1:58 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: HTT on current
>
>
> On Fri, Aug 22, 2003 at 10:23:52PM -0400, [EMAIL PROTECTED] wrote
Strange
Mine (Supermicro X5DAL-G) goes like ;
tyd3# dmesg
Copyright (c) 1992-2003 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.1-CURRENT #30: Sun Aug 24 20:25:
On Sun, Aug 24, 2003 at 01:06:28PM -0300, Marc G. Fournier wrote:
>
>
> ganymede# sysctl machdep.hlt_logical_cpus
> sysctl: unknown oid 'machdep.hlt_logical_cpus'
> ganymede# uname -a
> FreeBSD ganymede.hub.org 5.1-CURRENT FreeBSD 5.1-CURRENT #1: Sat Aug 23 00:08:54 ADT
> 2003 [EMAIL PROTECT
+--- On Saturday, August 23, 2003 21:18,
| [EMAIL PROTECTED] proclaimed:
|
| > On Fri, Aug 22, 2003 at 10:23:52PM -0400, [EMAIL PROTECTED] wrote:
| >> Well i've enabled all SMP options, recompiled and rebooted. The CPUs
| >> now properly show up in dmesg and i can see the C header in top.
| >> Howe
Did you do "sysctl machdep.hlt_logical_cpus=0"?
Default setting halt logical CPUs, and won't start HTT.
This is a kind of FAQ, and you will see a lot in the past
mailing-list.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinf
> On Fri, Aug 22, 2003 at 10:23:52PM -0400, [EMAIL PROTECTED] wrote:
>
>> Well i've enabled all SMP options, recompiled and rebooted. The CPUs now
>> properly show up in dmesg and i can see the C header in top. However no
>> processes seem to be being assigned to cpu 1. Why is the schedueler only
>
On Fri, Aug 22, 2003 at 10:23:52PM -0400, [EMAIL PROTECTED] wrote:
> Well i've enabled all SMP options, recompiled and rebooted. The CPUs now
> properly show up in dmesg and i can see the C header in top. However no
> processes seem to be being assigned to cpu 1. Why is the schedueler only
> using
> On Fri, Aug 22, 2003 at 07:03:03PM -0400, [EMAIL PROTECTED] wrote:
>> > That is not an SMP kernel. An SMP kernel (with APIC_IO) would not
>> print
>> > out
>> > the pcib0 interrupt routing messages.
>> >
>> > --
>>
>> So whats the problem here?
>
> See above.
>> How come the CPUs dont show up in
On Fri, Aug 22, 2003 at 07:03:03PM -0400, [EMAIL PROTECTED] wrote:
> > That is not an SMP kernel. An SMP kernel (with APIC_IO) would not print
> > out
> > the pcib0 interrupt routing messages.
> >
> > --
>
> So whats the problem here?
See above.
> How come the CPUs dont show up in top.
See abov
>> That is not an SMP kernel. An SMP kernel (with APIC_IO) would not print
>> out
>> the pcib0 interrupt routing messages.
>>
>> --
>
> So whats the problem here? How come the CPUs dont show up in top. How do i
> realy know the system sees 2, and actually utilizes them? Is there
> anything else i
> That is not an SMP kernel. An SMP kernel (with APIC_IO) would not print
> out
> the pcib0 interrupt routing messages.
>
> --
So whats the problem here? How come the CPUs dont show up in top. How do i
realy know the system sees 2, and actually utilizes them? Is there
anything else i have to do o
That is not an SMP kernel. An SMP kernel (with APIC_IO) would not print out
the pcib0 interrupt routing messages.
--
John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
-Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Kenneth Culver
> Sent: Friday, August 22, 2003 4:33 PM
> To: Mike Jakubik
> Cc: [EMAIL PROTECTED]
> Subject: Re: HTT on current
>
>
> > Hi,
> >
> > I have a HTT capa
> Hi,
>
> I have a HTT capabale PCU on an Intel MB with the 875P chipset. I have
> enabled HTT in the BIOS and compiled my kernel with the required SMP
> options, however i dont think the system is really running in SMP mode. Top
> does not display CPU numbers. Here is my dmesg:
>
> ---
>
> F
27 matches
Mail list logo