From owner-freebsd-current@FreeBSD.ORG Thu Apr 12 09:58:28 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 257DA16A40E; Thu, 12 Apr 2007 09:58:28 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.freebsd.org (Postfix) with ESMTP id 04DEC13C4C4; Thu, 12 Apr 2007 09:58:26 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (kdapat@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id l3C9wIs6062539; Thu, 12 Apr 2007 11:58:23 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id l3C9wHop062538; Thu, 12 Apr 2007 11:58:17 +0200 (CEST) (envelope-from olli) Date: Thu, 12 Apr 2007 11:58:17 +0200 (CEST) Message-Id: <200704120958.l3C9wHop062538@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG, des@des.no, Peter Jeremy , freebsd-fs@FreeBSD.ORG, Pawel Jakub Dawidek , ticso@cicely.de In-Reply-To: X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (FreeBSD/4.11-STABLE (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Thu, 12 Apr 2007 11:58:23 +0200 (CEST) Cc: Subject: Re: ZFS committed to the FreeBSD base. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@FreeBSD.ORG, des@des.no, Peter Jeremy , freebsd-fs@FreeBSD.ORG, Pawel Jakub Dawidek , ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2007 09:58:28 -0000 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 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