Re: ZFS committed to the FreeBSD base.

Dag-Erling Smørgrav wrote:
 > Peter Jeremy wrote:
 > > There's a feature bit (CPUID_CX8) that advertises the availability of
 > > cmpxchg8b (and maybe some related instructions).  My pre-MMX 586 has
 > > this bit set so I presume anything later than 486 will support it.
 > > (I'm not sure about the low-end VIA, GEODE etc clones).
 > 
 > The Geode is a 486, and does not support it.

No, it's a 586-class processor.  But you're right in
that it does not seem to support cmpxchg8b.  I have an
old 233 MHz Geode currently running FreeBSD 4.6 (please
no comments, it's my standalone mp3 player at home and
not connected to the internet so I didn't care to update
it yet, but I certainly will update it when I have some
time).  The kernel reports:

CPU: Cyrix GXm (232.74-MHz 586-class CPU)
  Origin = "CyrixInstead"  Id = 0x540  DIR=0x8246  Stepping=8  Revision=2

There's no "Features=" line, though.  Maybe the Geode
does not support the cpuid at all.  Whether it supports
cmpxchg8b is not 100% clear, but my guess would be "no".

 > The C3 however is a 586.

In fact it's a 686.

 > The C3 Ezra and C3 Samuel / Samuel 2 do not have CX8.
 > I'm not sure about the C3 Nehemiah, I don't have one
 > running at the moment.

I have a 1000 MHz C3 Nehemiah which is my home file server
(NFS and SMB), among other things (Squid, Apache, FW).
It does not support cmpxchg8b either, according to the
cpuid feature bits:

CPU: VIA C3 Nehemiah+RNG+AES (1002.28-MHz 686-class CPU)
  Origin = "CentaurHauls"  Id = 0x698  Stepping = 8
  Features=0x381b83f<FPU,VME,DE,PSE,TSC,MSR,SEP,MTRR,PGE,CMOV,PAT,MMX,FXSR,SSE>

It's currently running 6-stable, but I would very much
like to update it to -current and use ZFS for the file
server volumes.  I hope the absence of cmpxchg8b won't
make that impossible.

(It has 512 MB RAM, which should be sufficient to run
ZFS, right?  The squid process also takes quite some
memory, but I've configured it to be rather small.
After all this is only a private home server.  I'm not
planning to use compression, but maybe encryption (GELI)
for a small part of it.)

 > > I agree that GENERIC should run on lowest-common-denominator hardware
 > > (the definition of that is a subject for a different thread).  GENERIC
 > > performance could be enhanced by using an indirect call for 8-byte
 > > atomic instructions and selecting between the cmpxchg8b and
 > > alternative implementation as part of the CPU startup (much like
 > > i586_bcopy).  If CPU_486 is not defined, you code could inline the
 > > cmpxchg8b-based variant.

That wouldn't work on the C3 Nehemiah, I'm afraid.  CPU_486
is not defined there (in fact I only have I686_CPU in my
kernel config), but it does not support cmpxchg8b according
to the dmesg output above.  So the CPU class alone is not
sufficient to decide about the use of cmpxchg8b; you have
to check the actual CPU Features bit.

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

C++: "an octopus made by nailing extra legs onto a dog"
        -- Steve Taylor, 1998