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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html