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.
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.
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.
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to [EMAIL PROTECTED]
Please read the FAQ at http://kernelnewbies.org/FAQ
