Le vendredi 13 janvier 2012 à 11:35 +0100, Eric Dumazet a écrit :
> I wonder ...
>
> With 4096 cpus, do we really want to reserve 5242880 bytes of memory for
> this function ?
>
> What about following patch instead ?
>
> (Trying a dynamic memory allocation, and fallback on a single
> pre-allocated bloc of memory, shared by all cpus, protected by a
> spinlock)
>
> diff --git a/crypto/sha512_generic.c b/crypto/sha512_generic.c
> index 9ed9f60..5c80a76 100644
> --- a/crypto/sha512_generic.c
> +++ b/crypto/sha512_generic.c
> @@ -21,7 +21,6 @@
> #include <linux/percpu.h>
> #include <asm/byteorder.h>
>
> -static DEFINE_PER_CPU(u64[80], msg_schedule);
>
> static inline u64 Ch(u64 x, u64 y, u64 z)
> {
> @@ -87,10 +86,16 @@ static void
> sha512_transform(u64 *state, const u8 *input)
> {
> u64 a, b, c, d, e, f, g, h, t1, t2;
> -
> + static u64 msg_schedule[80];
> + static DEFINE_SPINLOCK(msg_schedule_lock);
> int i;
> - u64 *W = get_cpu_var(msg_schedule);
> + u64 *W = kzalloc(sizeof(msg_schedule), GFP_ATOMIC | __GFP_NOWARN);
>
And a plain kmalloc() is enough, since we fully initialize the array a
bit later.
for (i = 0; i < 16; i++)
LOAD_OP(i, W, input);
for (i = 16; i < 80; i++) {
BLEND_OP(i, W);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
