I think that it is not gpg-agent but pinentry which causes millions of futex syscall errors.
For interactive use case, pinentry may be the point of contention.
I might be wrong if your key is not protected by passphrase.

If possible, please try adding arguments for gpg invocation: --pinentry-mode loopback --passphrase-file YOUR_FILE_FOR_PASSPHRASE
This can avoid the invocation of pinentry entirely.

Note that you actually run 30 independent processes with gpg 1.4 but with gpg-agent there is just one process to handle the private key operations (decrypt). To utilize more cores you need to setup several GNUPGHOME with the same private keys.

In T5137#139064, @gniibe wrote:

I think that it is not gpg-agent but pinentry which causes millions of futex syscall errors.
For interactive use case, pinentry may be the point of contention.
I might be wrong if your key is not protected by passphrase.

If possible, please try adding arguments for gpg invocation: --pinentry-mode loopback --passphrase-file YOUR_FILE_FOR_PASSPHRASE
This can avoid the invocation of pinentry entirely.

I've tried running gpg with "--pinentry-mode loopback" (+gpg-agent is running with "--allow-loopback-pinentry" to make sure it is allowed) -- did not change the situation.
Worth mentioning, the gpg private key we are using isn't password protected.

In T5137#139066, @werner wrote:

Note that you actually run 30 independent processes with gpg 1.4 but with gpg-agent there is just one process to handle the private key operations (decrypt). To utilize more cores you need to setup several GNUPGHOME with the same private keys.

Yeah, this must be it.

In T5137#139068, @werner wrote:

I change this to a feature request: Allow several processes to run public key decryption using the same set of private keys.

Thank you, Werner!

Thanks. I understand the situation. Basically, gpg-agent's computation is done by a single thread (in current implementation), although it accepts many requests simultaneously.

For an experiment, I tried following patch to allow computation by multiple threads.
It is not yet complete because it's only for decryption (not for signing) and protect.c is shared by other commands, but it's worth a try.

diff --git a/agent/pkdecrypt.c b/agent/pkdecrypt.c
index ec23daf83..be2e54679 100644
--- a/agent/pkdecrypt.c
+++ b/agent/pkdecrypt.c
@@ -26,6 +26,7 @@
 #include <unistd.h>
 #include <sys/stat.h>
 
+#include <npth.h>
 #include "agent.h"
 
 
@@ -105,7 +106,9 @@ agent_pkdecrypt (ctrl_t ctrl, const char *desc_text,
 /*           gcry_sexp_dump (s_skey); */
 /*         } */
 
+      npth_unprotect ();
       rc = gcry_pk_decrypt (&s_plain, s_cipher, s_skey);
+      npth_protect ();
       if (rc)
         {
           log_error ("decryption failed: %s\n", gpg_strerror (rc));
diff --git a/agent/protect.c b/agent/protect.c
index 54666e717..ebc1a417a 100644
--- a/agent/protect.c
+++ b/agent/protect.c
@@ -37,6 +37,7 @@
 # include <sys/times.h>
 #endif
 
+#include <npth.h>
 #include "agent.h"
 
 #include "cvt-openpgp.h"
@@ -1451,17 +1452,23 @@ hash_passphrase (const char *passphrase, int hashalgo,
                  unsigned long s2kcount,
                  unsigned char *key, size_t keylen)
 {
+  int r;
+
   /* The key derive function does not support a zero length string for
      the passphrase in the S2K modes.  Return a better suited error
      code than GPG_ERR_INV_DATA.  */
   if (!passphrase || !*passphrase)
     return gpg_error (GPG_ERR_NO_PASSPHRASE);
-  return gcry_kdf_derive (passphrase, strlen (passphrase),
-                          s2kmode == 3? GCRY_KDF_ITERSALTED_S2K :
-                          s2kmode == 1? GCRY_KDF_SALTED_S2K :
-                          s2kmode == 0? GCRY_KDF_SIMPLE_S2K : GCRY_KDF_NONE,
-                          hashalgo, s2ksalt, 8, s2kcount,
-                          keylen, key);
+
+  npth_unprotect ();
+  r = gcry_kdf_derive (passphrase, strlen (passphrase),
+                       s2kmode == 3? GCRY_KDF_ITERSALTED_S2K :
+                       s2kmode == 1? GCRY_KDF_SALTED_S2K :
+                       s2kmode == 0? GCRY_KDF_SIMPLE_S2K : GCRY_KDF_NONE,
+                       hashalgo, s2ksalt, 8, s2kcount,
+                       keylen, key);
+  npth_protect ();
+  return r;
 }

I though about this too but we need to take care about the logging functions of Libgcrypt which are intertwined with nPth (clamp function of libgpg-error).