Re: [PATCH][RFC] random: show /dev/random statistics per interface, kernel 2.6.26.1

[Rene Herman <rene.herman@xxxxxxxxxxxx>]

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 ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ