On Wed, Apr 25, 2018 at 7:41 PM, Bernhard Voelker
<m...@bernhard-voelker.de> wrote:
> On 04/25/2018 01:26 PM, Matteo Croce wrote:
>> +#define BLOCKSIZE 32768
>
> Did you try different buffer sizes?
>
> In coreutils, we have a little script to determine the optimal BLOCKSIZE
> - which is 128*1024 since 2014:
>
> https://git.sv.gnu.org/cgit/coreutils.git/tree/src/ioblksize.h?id=22424dde74d0
>
Hi Bernhard,
I knew it and I tried different blocksizes too, but for some odd
reason there are no improvements with block size past 16k, so I left
the old value which was 32k. These are
the timings of sha1sum on a 16g file:
1024 22.991s
2048 18.609s
4096 16.397s
8192 15.255s
16384 14.544s
32768 14.126s
65536 15.396s
131072 15.247s
262144 13.713s
524288 15.141s
1048576 15.139s
I have an Intel i7 i7-6700K CPU and a recent kernel with mitigations
enabled for Meltdown, which should give a penality on every context
switch, this is why I say "for some odd reason" :)
Keep in mind that with files smaller than 2 GB the whole hash will be
calculated with a single call to sendfile()
>
>> +#ifdef AF_ALG
>> + int ret;
>> +
>> + ret = afalg_stream(stream, resblock, "sha1", SHA1_DIGEST_SIZE);
>> + if (!ret)
>> + return 0;
>> +
>> + if (ret == -EIO)
>> + return 1;
>> +#endif
>
> afalg_stream also returns other errors, namely EAFNOSUPPORT and EINVAL,
> which should be handled as well, right?
>
EAFNOSUPPORT means that af_alg is not supported, hence the generic C
code is used as fallback.
EINVAL means that an string longer than
sizeof(sockaddr_alg.sockaddr_alg) is passed to afalg_stream().
This is impossible as we pass the constant value "sha1" to afalg_stream().
> Thanks & have a nice day,
> Berny
Thanks, have a nice day too.
--
Matteo Croce
per aspera ad upstream
