FreeBSD is now self-hosting on the UltraSPARC T1
Kip Macy
it can "make buildworld" natively.
The source is currently available in perforce under the view
//depot/projects/kmacy_sun4v/... I probably won't roll it back into
CVS until the logical domaining support is done. I'm looking forward
to receiving input from individuals who plan to deploy it to find out
what workloads to target in performance tuning.
-Kip
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"
Xin LI
在 2006-05-20六的 22:19 -0700，Kip Macy写道：
> I'm proud to announce that FreeBSD on the T1 is now stable enough that
> it can "make buildworld" natively.
That's great news! Thanks for the hard work!
> The source is currently available in perforce under the view
> //depot/projects/kmacy_sun4v/... I probably won't roll it back into
I will try to see if I can get access to an UltraSPARC T1 box at company
to try this out.
> CVS until the logical domaining support is done. I'm looking forward
> to receiving input from individuals who plan to deploy it to find out
> what workloads to target in performance tuning.
I think that to encourage more tests, you would probably want to provide
a downloadable copy of the output of "p4 diff" since we do not provide
anonymous p4 access for outside developers (yet) :-)
Cheers,
--
Xin LI <delphij delphij net> http://www.delphij.net/
Poul-Henning Kamp
>I'm proud to announce that FreeBSD on the T1 is now stable enough that
>it can "make buildworld" natively.
Bravo!
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de
Maxim Sobolev
-Maxim
Kip Macy
I think that FreeBSD can add a couple of lines to its own website
:-).
-Kip
Christian Brueffer
> If Linux can get a CNET article about just partially booting on the T1
> I think that FreeBSD can add a couple of lines to its own website
> :-).
>
> -Kip
Great news! Does the following look ok?
Index: news.xml
===================================================================
RCS file: /data/ncvs/freebsd/www/en/news/news.xml,v
retrieving revision 1.398
diff -u -r1.398 news.xml
--- news.xml 17 May 2006 21:13:37 -0000 1.398
+++ news.xml 21 May 2006 09:34:19 -0000
@@ -32,6 +32,22 @@
<name>5</name>
<day>
+ <name>21</name>
+ <event>
+ <title>FreeBSD Self-Hosting on the Sun T1 Processor</title>
+
+ <p>FreeBSD is now able to complete a full run of the
+ "make buildworld" command on machines running the Sun T1
+ processor with CoolThreads technology, and is thus self-hosting.
+ The code currently resides in the <a
+ href="http://perforce.freebsd.org/branchView.cgi?BRANCH=kmacy%5fsun4v">
+ FreeBSD Perforce revision control system</a> and will be merged to
+ the official CVS repository, once support for logical domaining
+ is complete</p>
+ </event>
+ </day>
+
+ <day>
<name>17</name>
<event>
<p>New committer: <a
- Christian
--
Christian Brueffer ch...@unixpages.org brue...@FreeBSD.org
GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc
GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D
Christian Brueffer
> On Sun, May 21, 2006 at 12:20:14AM -0700, Kip Macy wrote:
> > If Linux can get a CNET article about just partially booting on the T1
> > I think that FreeBSD can add a couple of lines to its own website
> > :-).
> >
> > -Kip
>
> Great news! Does the following look ok?
>
New version after input from maxim@:
Index: news.xml
===================================================================
RCS file: /data/ncvs/freebsd/www/en/news/news.xml,v
retrieving revision 1.398
diff -u -r1.398 news.xml
--- news.xml 17 May 2006 21:13:37 -0000 1.398
+++ news.xml 21 May 2006 09:52:19 -0000
@@ -32,6 +32,23 @@
<name>5</name>
<day>
+ <name>21</name>
+ <event>
+ <title>FreeBSD Self-Hosting on the Sun T1 Processor</title>
+
+ <p>FreeBSD is now able to complete a full run of the
+ "make buildworld" command on machines running the <a
+ href="http://www.sun.com/processors/UltraSPARC-T1/">Sun T1 processor
+ with CoolThreads technology</a>, and is thus self-hosting.
+ The code currently resides in the <a
+ href="http://perforce.freebsd.org/branchView.cgi?BRANCH=kmacy%5fsun4v">
+ FreeBSD Perforce revision control system</a> and will be merged to
+ the official CVS repository, once support for logical domaining
+ is complete.</p>
Will Andrews
> I think that to encourage more tests, you would probably want to provide
> a downloadable copy of the output of "p4 diff" since we do not provide
> anonymous p4 access for outside developers (yet) :-)
Actually we do, although it's not via p4 but rather cvsup.
cvsup10 and cvsup18 should carry everything that's in perforce.
Maybe with a few minor exceptions.
--
wca
Kip Macy
-Kip
Robert Watson
In general, cvsup10 (and presumably 18?) carry only a small subset of Perforce
-- they explicitly export certain branches. In the past, the CVS exporter has
proven a bit unreliable in the context of TrustedBSD -- it occasionally breaks
when it finds something it doesn't like, require administrator fixing, etc.
Robert N M Watson
Kip Macy
> On Sat, May 20, 2006 at 10:19:58PM -0700, Kip Macy wrote:
> > I'm proud to announce that FreeBSD on the T1 is now stable enough that
> > it can "make buildworld" natively.
>
> Excellent work!
> When can I start breaking it? :)
As soon as someone can provide you with a T1000 or T2000 - I think
Paul may already have one. I went out of my way to make sure that:
export MAKEOBJDIRPREFIX=<objpath>; make buildworld TARGET_ARCH=sparc64
TARGET=sun4v; make buildkernel TARGET_ARCH=sparc64 TARGET=sun4v; su;
make installworld TARGET_ARCH=sparc64 TARGET=sun4v DESTDIR=<path>;
make installkernel TARGET_ARCH=sparc64 TARGET=sun4v DESTDIR=<path>;
would just work straight out of perforce.
I ended up doing make -j8 buildworld because make -j32 exposed a panic
inducing race in NFS about 30 minutes in.
I'm really looking forward to seeing what kind of locking contention
we're getting in the kernel.
Kip Macy
dmesg to link to.
http://www.fsmware.com/sun4v/dmesg_latest.txt
On 5/21/06, Christian Brueffer <brue...@freebsd.org> wrote:
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"
--
Will Andrews
> In general, cvsup10 (and presumably 18?) carry only a small subset of
> Perforce -- they explicitly export certain branches. In the past, the CVS
> exporter has proven a bit unreliable in the context of TrustedBSD -- it
> occasionally breaks when it finds something it doesn't like, require
> administrator fixing, etc.
OK, my apologies for the misinformation.
--
wca
Joao Barros
> I can't find the original e-mail, but someone was suggesting I post a
> dmesg to link to.
>
> http://www.fsmware.com/sun4v/dmesg_latest.txt
I'm wondering, Sun provided the machine along with documentation to
enable FreeBSD to run on it. But booting is one thing, making use of
all of the machine is another:
pci9: <mass storage, ATA> at device 8.0 (no driver attached)
pci10: <serial bus, Fibre Channel> at device 1.0 (no driver attached)
pci10: <mass storage, SCSI> at device 2.0 (no driver attached)
Did they provide documentation for IDE, SCSI, RAID and Fibre
controllers the machine has?
Not to bite the hand of Sun but just wondering if they gave just a
hand or the whole arm ;-)
PS: Good job!
--
Joao Barros
Kip Macy
late in boot when I enable isp. The LSI SAS card uses the MPT driver
which isn't big-endian safe yet. So information isn't the problem in
this case.
-Kip
m m
> I can't find the original e-mail, but someone was suggesting I post a
> dmesg to link to.
>
> http://www.fsmware.com/sun4v/dmesg_latest.txt
...
FreeBSD/SMP: Multiprocessor System Detected: 32 CPUs
...
SMP: AP CPU #31 Launched!
SMP: AP CPU #30 Launched!
SMP: AP CPU #29 Launched!
SMP: AP CPU #28 Launched!
...
Some phylosophical questions - is this machine really an SMP? Can we
have an "SMP" when there's only one chip? (it's CMT/CMP, isn't it?)
Can we perhaps stop calling any MP an "SMP" one of these days? While
on topic, the Opterons aren't SMP either, and neither are the
ht-Xeons... but we somehow keep lumping them into the "SMP" category.
Maybe we should fix this once and for all? Won't it be weird to
write page-allocation code for NUMA machines and put the code into an
SMP directory? What about coloring algorithms on the T1000 to improve
locality in it's funky cache hierarchy, are we going to put that under
"SMP" category too? Who was it that decided that all the world that
has more than core is an SMP?
(please pardon the format of this mail - but I really only have
questions, no answers...)
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"
--
Bachilo Dmitry
Well, this is 8-core processor, so it is pretty an SMP system, made to have
cheeper multiprocessing then what we call "real" multiprocessor system does.
Sun says that it is much wiser to place more cores then to populate PUs and
they themselves call Niagara-powered (UltraSPARC T1) systems a 32-processor
systems. So why not call it SMP? We say SMP when we want to say that there
are many processing devices (cores), noone say that there must be many CPUs
on the mainboard. On the other hand, thread and HT is not a physical core, so
here I should agree - it's not SMP, it's stupid HT or great multithreading
T1.
Nevertheless I am shure that noone want to break the tradition or rewrite the
system just to forget this term....
------------------------
С уважением, Бачило Дмитрий
Руководитель отдела системной интеграции
ООО "Компания СоЛинк"
Peter Jeremy
>? ????????? ?? ??????????? 22 ??? 2006 08:54 m m ???????(a):
>> Some phylosophical questions - is this machine really an SMP? Can we
>Well, this is 8-core processor, so it is pretty an SMP system, made to have
>cheeper multiprocessing then what we call "real" multiprocessor system does.
I don't think m m is referring to the cores but the NUMA: The CPUs
aren't all equivalent so it's not 'symmetric'. OTOH, it's not the
same as (eg) the IBM S/370 CPU+AP systems where the AP couldn't handle
interrupts.
--
Peter Jeremy
Chad Leigh -- Shire.Net LLC
On May 21, 2006, at 7:54 PM, m m wrote:
> While
> on topic, the Opterons aren't SMP either, and neither are the
> ht-Xeons...
I would like t\o hear the rational for the Opterons (presumably the
dual core ones) not being SMP. They have two independent operating
cores in one physical package. Who cares how it is packaged? I
would tend to agree with you on the ht-Xeon in terms of general
descriptions. I do not know as well how the ht-xeon work as I don't
use any but it seems to me that the "SMP" moniker, at least in
FreeBSD, relate to how things are scheduled.
Btw, Opteron MB with a single dual-core ship get a BIOS report on
Boot of having 2 CPUs...
Chad
---
Chad Leigh -- Shire.Net LLC
Your Web App and Email hosting provider
chad at shire.net
Eric Anderson
>
> On May 21, 2006, at 7:54 PM, m m wrote:
>
>> While
>> on topic, the Opterons aren't SMP either, and neither are the
>> ht-Xeons...
>
> I would like t\o hear the rational for the Opterons (presumably the dual
> core ones) not being SMP. They have two independent operating cores in
> one physical package. Who cares how it is packaged? I would tend to
> agree with you on the ht-Xeon in terms of general descriptions. I do
> not know as well how the ht-xeon work as I don't use any but it seems to
> me that the "SMP" moniker, at least in FreeBSD, relate to how things are
> scheduled.
>
> Btw, Opteron MB with a single dual-core ship get a BIOS report on Boot
> of having 2 CPUs...
Careful - two cores doesn't mean two caches, and isn't always just 'two
cores glued into one package'.
Eric
--
------------------------------------------------------------------------
Eric Anderson Sr. Systems Administrator Centaur Technology
Anything that works is better than anything that doesn't.
------------------------------------------------------------------------
Chad Leigh -- Shire.Net LLC
On May 22, 2006, at 10:34 AM, Eric Anderson wrote:
> Chad Leigh -- Shire.Net LLC wrote:
>> On May 21, 2006, at 7:54 PM, m m wrote:
>>> While
>>> on topic, the Opterons aren't SMP either, and neither are the
>>> ht-Xeons...
>> I would like t\o hear the rational for the Opterons (presumably
>> the dual core ones) not being SMP. They have two independent
>> operating cores in one physical package. Who cares how it is
>> packaged? I would tend to agree with you on the ht-Xeon in terms
>> of general descriptions. I do not know as well how the ht-xeon
>> work as I don't use any but it seems to me that the "SMP" moniker,
>> at least in FreeBSD, relate to how things are scheduled.
>> Btw, Opteron MB with a single dual-core ship get a BIOS report on
>> Boot of having 2 CPUs...
>
> Careful - two cores doesn't mean two caches, and isn't always just
> 'two cores glued into one package'.
>
But on the Opteron, the subject of the discussion, it does. They
have two caches. The Intel Core Duo dies not.
Chad
> -------------------------------------------------------------------
---
Chad Leigh -- Shire.Net LLC
Your Web App and Email hosting provider
chad at shire.net
_______________________________________________
m m
>
> On May 21, 2006, at 7:54 PM, m m wrote:
>
> > While
> > on topic, the Opterons aren't SMP either, and neither are the
> > ht-Xeons...
>
> I would like t\o hear the rational for the Opterons (presumably the
> dual core ones) not being SMP. They have two independent operating
> cores in one physical package. Who cares how it is packaged? I
> would tend to agree with you on the ht-Xeon in terms of general
> descriptions. I do not know as well how the ht-xeon work as I don't
> use any but it seems to me that the "SMP" moniker, at least in
> FreeBSD, relate to how things are scheduled.
SMP stands for "Symmetric MultiProcessing", which means that multiple
processors have equal access latency to memory - typically
accomplished by sitting the processors on a shared bus with memory.
The MultiProcessor Opterons are _NOT_ SMP, they are _NUMA_ machines,
"NonUniform Memory Access"; in the MP Opterons each processor has (or
can have) its own "local" memory, which makes up only part of the
shared address space. When an Opteron accesses an address that is not
in its "local" memory, it has to talk to a remote processor's memory,
thereby incurring a different access latency.
Chad Leigh -- Shire.Net LLC
On May 22, 2006, at 12:33 PM, m m wrote:
> On 5/22/06, Chad Leigh -- Shire.Net LLC <ch...@shire.net> wrote:
>>
>> On May 21, 2006, at 7:54 PM, m m wrote:
>>
>> > While
>> > on topic, the Opterons aren't SMP either, and neither are the
>> > ht-Xeons...
>>
>> I would like t\o hear the rational for the Opterons (presumably the
>> dual core ones) not being SMP. They have two independent operating
>> cores in one physical package. Who cares how it is packaged? I
>> would tend to agree with you on the ht-Xeon in terms of general
>> descriptions. I do not know as well how the ht-xeon work as I don't
>> use any but it seems to me that the "SMP" moniker, at least in
>> FreeBSD, relate to how things are scheduled.
>
> SMP stands for "Symmetric MultiProcessing", which means that multiple
> processors have equal access latency to memory - typically
> accomplished by sitting the processors on a shared bus with memory.
> The MultiProcessor Opterons are _NOT_ SMP, they are _NUMA_ machines,
> "NonUniform Memory Access"; in the MP Opterons each processor has (or
> can have) its own "local" memory, which makes up only part of the
> shared address space. When an Opteron accesses an address that is not
> in its "local" memory, it has to talk to a remote processor's memory,
> thereby incurring a different access latency.
Yes, but until FBSD differentiates and has different code for "SMP"
and "NUMA" based systems, then having support for them in the SMP
branch seems appropriate. In other words, even if not ideal, if
there is no different code, there doesn't need to be a different
section for the code. I am no expert, but as far as I can tell, FBSD
treats them like an SMP system and the NUMA stuff is done at the HW
level. Correct me if I am wrong. Seems like the SMP moniker is a
historical one, not a technical one :-)
---
Chad Leigh -- Shire.Net LLC
Your Web App and Email hosting provider
chad at shire.net
_______________________________________________
Claus Guttesen
> > The MultiProcessor Opterons are _NOT_ SMP, they are _NUMA_ machines,
Not really related to the original topic any longer, is it?
regards
Claus
Wilko Bulte
> >>> > on topic, the Opterons aren't SMP either, and neither are the
> >ht-Xeons...
> >> The MultiProcessor Opterons are _NOT_ SMP, they are _NUMA_ machines,
>
Decent bikesheds never are..
:)
--
Wilko Bulte wi...@FreeBSD.org
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"
--
Darren Pilgrim
> On Mon, May 22, 2006 at 09:43:11PM +0200, Claus Guttesen wrote..
>>>>>> on topic, the Opterons aren't SMP either, and neither are the
>>> ht-Xeons...
>>>>> ...
>>>> The MultiProcessor Opterons are _NOT_ SMP, they are _NUMA_ machines,
>> Not really related to the original topic any longer, is it?
>
> Decent bikesheds never are..
At least people are being polite and not messing up the threading by
changing the subject header. :)
--
Darren Pilgrim
Lars Heidieker
Hash: SHA1
> To unsubscribe, send any mail to "freebsd-current-
> unsub...@freebsd.org"
>
I don't think this is right, SMP stands for "Symmetric
MultiProcessing" in opposite to MultiProcessing where the OS image runs
only on one CPU UMA and NUMA are a different thing, but yes a NUMA
machine with big latency differences would have
problems to run efficiently as a SMP machine.
Therefor a dual core Opteron has SMP (two cores two caches etc) and
totally UMA and a dual single core Opteron is not
because it is NUMA. I don't take if this is the result.
For me I would seperate NUMA/UMA from SMP and call it SMP if there
are more than one processor core.
Yes this leaves Intels HT in the dark I don't know if I would call
that SMP, but probably I would as it appears (to the os) to be two cpus.
Lars
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)
iD8DBQFEcsRTcxuYqjT7GRYRAmBwAJ9CTYwCsQlClJX+jXwl+U/rtUv0MQCgrAqo
2+MZhRW8kDdSGAvQp0mFE+c=
=fDqM
-----END PGP SIGNATURE-----
Lars Heidieker
Hash: SHA1
On 22 May 2006, at 22:26, Darren Pilgrim wrote:
> Wilko Bulte wrote:
>> On Mon, May 22, 2006 at 09:43:11PM +0200, Claus Guttesen wrote..
>>>>>>> on topic, the Opterons aren't SMP either, and neither are the
>>>> ht-Xeons...
>>>>>> ...
>>>>> The MultiProcessor Opterons are _NOT_ SMP, they are _NUMA_
>>>>> machines,
>>> Not really related to the original topic any longer, is it?
>> Decent bikesheds never are..
>
> At least people are being polite and not messing up the threading
> by changing the subject header. :)
>
Yes that would be extremely NUMA because of the latencies occurring
with such a thread migration ;-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)
iD8DBQFEcsT1cxuYqjT7GRYRAhXZAJ9YGIW279AByboC9V4VRnYG78pprwCguRWR
E9GIqAo+y9AeNulP2rMcX5o=
=xW9J
-----END PGP SIGNATURE-----
Astrodog
As a side note here, I'm working on the Opteron-isnt-SMP thing at the
moment.... I'm just calling it "OPTERON", since.... well.... nothing
else fits with it very well, and nothing else FreeBSD runs on supports
it anyway, I believe.
>From what I can tell, it would be.... unwise to classify Opteron as
NUMA, atleast to the kernel, since the overhead for real NUMA
clusters, with scheduling, and VM stuff would be somewhat excessive.
Opteron is logically NUMA, (When using multiple sockets), but
practically, I'm finding there's an excessive performance penalty when
you try to treat it strictly as such, as compared to calling it SMP,
so the implimentation is actually ending up somewhere in between.
Note that the above applies only to MULTIPLE SOCKETS. A dual core
Opteron, or Athlon64 X2 in a single socket is, in every sense of the
word, SMP.
I don't even want to get into naming nightmare of multiple dual core
Opterons. ;)
As for Intel's HT.... I suggest, "EXTRA_OVERHEAD_JUST_FOR_FUN", or
alternately, "LEAVE_THE_EBRAKE_ON". Perhaps in light of Colin's
thing.... "READ_MY_KEYS" would work, too.
--- Harrison Grundy