Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 21 Nov 2016 19:35:48 +0100
From:      Jan Bramkamp <crest@rlwinm.de>
To:        svn-src-all@freebsd.org
Subject:   Re: svn commit: r308869 - head/sbin/nvmecontrol
Message-ID:  <def475f6-09c0-7e44-4d26-71db9c59725d@rlwinm.de>
In-Reply-To: <123365400.XYmKG93e4H@ralph.baldwin.cx>
References:  <201611192146.uAJLkDP5094317@repo.freebsd.org> <123365400.XYmKG93e4H@ralph.baldwin.cx>

next in thread | previous in thread | raw e-mail | index | archive | help


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=<foo> where <foo> 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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?def475f6-09c0-7e44-4d26-71db9c59725d>