On Tue, Jul 29, 2025 at 9:38 AM Dagfinn Ilmari Mannsåker <ilm...@ilmari.org> wrote: > > Jacob Champion <jacob.champ...@enterprisedb.com> writes: > > > On Mon, Jul 28, 2025 at 6:30 PM Michael Paquier <mich...@paquier.xyz> wrote: > > > >> Could getentropy() be more efficient at the end on most platforms, > >> meaning that this could limit the meaning of having a GUC switch? > > > > I don't know. [2] implies that the performance comparison depends on > > several factors, and falls in favor of OpenSSL when the number of > > bytes per call is large > [...] > > [2] https://dotat.at/@/2024-10-01-getentropy.html > > Note that that test was done on an older Linux kernel without the vDSO > implementation of getentropy(), so on newer kernel (>=6.11) and glibc > (>= 2.41) versions the difference might be smaller or the other way > around.
FYI I've benchmarked vDSO implementation of getrandom() with Fedora 42
(kernel 6.15, glibc 2.41). I've modified the test program linked by
the blog post[1] so that it measures vDSO implementation of
getrandom() and directly calling getrandom system call. I've attached
the test program. Here is the result:
$ ./bench
init openssl 1929533
len entropy openssl vgetrandom getrandom
16 353 400 39 235
64 373 401 125 368
256 675 420 432 664
1024 2651 494 1352 1792
The 'vgetrandom' column shows nanoseconds per function call of vDSO
implementation of getrandom() function whereas the 'getrandom' column
shows nanoseconds per getrandom system call.
For smaller bytes, vgetrandom (i.e., simply calling the getrandom()
function) is much faster than other methods. For larger bytes (such
1024), openssl had the best performance. This fact is very attractive
to me in terms of using it for UUID generation.
Regards,
[1] https://dotat.at/@/2024-10-01-getentropy.html
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
bench.c
Description: Binary data
