Rene Herman wrote on 20.08.2008 22:52:
On 20-08-08 20:21, Stanichenko Marat wrote:
- credit_entropy_bits(&input_pool,
- min_t(int, fls(delta>>1), 11));
+ nbits = min_t(int, fls(delta>>1), 11);
+ spin_lock_irqsave(&state->lock, flags);
+ state->nbits += nbits;
+ spin_unlock_irqrestore(&state->lock, flags);
+ credit_entropy_bits(&input_pool,nbits);
Couldn't state->nbits be an atomic_t? The locking looks like it might
be a little expensive. Maybe they should be per-cpu? I have no idea
about the frequencies here...
I've thought about this:
about atomic_t:
- atomic_t might be 2^24 as a maximum value (on SPARC arch). I've
created VMWare test machine and left it without any special load for a
day. Then I measured the value of produced entropy. The max number was
about 30000. 2^24/30000 ~ 559 days without overflowing. I don't know
if it suits for our purpose... that's why I rejected this approach.
Okay, no real opinion there but there's also an atomic_long_t.
Thanks again. I'll try to learn abouth atomic_long_t and if it's really
works as I think I'll use them instead of disable irq and locking
because it really seems ugly. :)
about per-cpu variables:
- the function called with interrupts enable so if I use spinlock I
must disable interrupts, am I right?
The question does not seem related to per-cpu variables. Note that per
cpu data can be accessed locklessly.
It was misprinting I've ment the following: the function might be called
with interrupts enable so if I use PER_CPU variables I have do disable
interrups on this CPU.
I don't know if there's a good tutorial on them but see <linux/percpu.h>
You declare them with DEFINE_PER_CPU() and access them with
{get,put}_cpu_var().
In fact, now that I'm grepping, Documentation/local_ops.txt looks
interesting here.
Rene.
I am really grateful to you for the help. I'll try to improve my patch
and resend it.
Stanichenko Marat
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
