[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1326458124.3826.6.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
Date: Fri, 13 Jan 2012 13:35:24 +0100
From: Eric Dumazet <eric.dumazet@...il.com>
To: David Laight <David.Laight@...LAB.COM>
Cc: Herbert Xu <herbert@...dor.apana.org.au>,
Alexey Dobriyan <adobriyan@...il.com>,
linux-crypto@...r.kernel.org, netdev@...r.kernel.org,
ken@...elabs.ch, Steffen Klassert <steffen.klassert@...unet.com>
Subject: RE: sha512: make it work, undo percpu message schedule
Le vendredi 13 janvier 2012 à 11:45 +0000, David Laight a écrit :
> > Trying a dynamic memory allocation, and fallback on a single
> > pre-allocated bloc of memory, shared by all cpus, protected by a
> > spinlock
> ...
> > -
> > + 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);
> >
> > +
> > + if (!W) {
> > + spin_lock_bh(&msg_schedule_lock);
> > + W = msg_schedule;
> > + }
>
> If this code can be called from an ISR is the kmalloc()
> call safe?
>
Yes, obviously, kmalloc() is IRQ safe.
> If the above is safe, wouldn't it be better to:
> 1) try to use the static buffer
> 2) try to kalloc() a buffer
> 3) spinwait for the static buffer to be free
>
No idea of what you mean, and why you think its better.
kmalloc() propably can give us a block already hot in cpu cache.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists