[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20150520154205.GA13539@gondor.apana.org.au>
Date: Wed, 20 May 2015 23:42:05 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc: Theodore Ts'o <tytso@....edu>,
Steffen Klassert <steffen.klassert@...unet.com>,
Jaegeuk Kim <jaegeuk@...nel.org>,
"David S. Miller" <davem@...emloft.net>,
"linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
linux-ext4@...r.kernel.org,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
linux-f2fs-devel@...ts.sourceforge.net, ecryptfs@...r.kernel.org,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] crypto: allow to assign gfp_t for __crypto_alloc_tfm
On Wed, May 20, 2015 at 05:30:14PM +0200, Ard Biesheuvel wrote:
>
> However, it's quite a can of worms you're opening here. Speed is
> easily quantified, and it may even be feasible to introduce some kind
> of boottime benchmark to select the fastest implementation available
> (like already exists for xor and raid6, for instance).
> @Herbert: was something like this ever proposed? And would you
> consider merging it if it were implemented adequately?
Up until now static priorities have been sufficient in selecting
the best implementation. However, if you can show us a case where
a given implementation is slower on one host but faster on another
then sure we can add a run-time test and priority adjustment for it.
Cheers,
--
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists