From owner-svn-src-all@freebsd.org Mon Nov 21 18:35:50 2016 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E510DC4D624 for ; Mon, 21 Nov 2016 18:35:50 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from smtp.rlwinm.de (smtp.rlwinm.de [IPv6:2a01:4f8:201:31ef::e]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B11D0121D for ; Mon, 21 Nov 2016 18:35:50 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from vader9.bultmann.eu (unknown [87.253.189.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.rlwinm.de (Postfix) with ESMTPSA id 4FED85847 for ; Mon, 21 Nov 2016 19:35:49 +0100 (CET) Subject: Re: svn commit: r308869 - head/sbin/nvmecontrol To: svn-src-all@freebsd.org References: <201611192146.uAJLkDP5094317@repo.freebsd.org> <123365400.XYmKG93e4H@ralph.baldwin.cx> From: Jan Bramkamp Message-ID: Date: Mon, 21 Nov 2016 19:35:48 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <123365400.XYmKG93e4H@ralph.baldwin.cx> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2016 18:35:51 -0000 On 21/11/2016 19:07, John Baldwin wrote: > On Saturday, November 19, 2016 09:46:13 PM Warner Losh wrote: >> Author: imp >> Date: Sat Nov 19 21:46:13 2016 >> New Revision: 308869 >> URL: https://svnweb.freebsd.org/changeset/base/308869 >> >> Log: >> i386 turns out to not have __uint128_t. So confusingly use 64-bit math >> instead. Since we're little endian, we can get away with it. Also, >> since the counters in quesitons would require billions of iops for >> tens of billions of seconds to overflow, and since such data rates are >> unlikely for people using i386 for a while, that's OK. The fastest >> cards today can't do even a million IOPs. >> >> Noticed by: dim@ >> Sponsored by: Netflix, Inc > > It probably has it if you compile with -march= where is new > enough to have SSE. In that case you have 128-bit registers. Starting with SSE2 you use those registers for 4 x 32-bit integer computations but irrc SSE lacks efficient carry operations. It's probably still more efficient to user 32-bit integer registers for bignum operations unless you want to (ab-)use the 53-bit multipliers hidden inside the FPUs. I don't know if correctly aligned memory transfers between SSE registers and memory are atomic. Unless SSE can provide this guarantee there advantage to polluting the code with SIMD built-ins. > Is nvme inherently x86-only? No.