Messages in this thread | | | Date | Tue, 01 Dec 2009 09:18:49 +0000 | From | Ian Molton <> | Subject | Re: [PATCH 1/2] hw_random: core updates to allow more efficient drivers |
| |
Matt Mackall wrote: > On Mon, 2009-11-30 at 10:28 +0000, Ian Molton wrote: >> Rusty Russell wrote: >> >>> And might as well just #defube RNG_BUFFSIZE SMP_CACHE_BYTES (or use >>> SMP_CACHE_BYTES here and sizeof() elsewhere). >> This can lead to a rather small (4 byte) buffer on some systems, however >> I don't know if in practice a tiny buffer or a big one would be better >> for performance on those machines. I guess if its a problem someone can >> patch the code to allocate a minimum of (say) 16 bytes in future... > > Hmmm, I think this was bad advice from Rusty.
Not entirely...
> The goal is to size and align the buffer so that we know it will always > work. Thus 64 bytes (always big enough but not so big that anyone will > complain) and cache aligned (makes stupid things like Via Padlock happy > -on Vias-).
yep. Although making it the size of a cacheline makes sense on /most/ modern architectures - 32 bytes is a very common size - I think the (current) worst case is one of the drivers wants to dump 3 u64s in one go. virtio-rng will take what it can...
> Rusty's suggestion could easily have us in trouble if some driver wants > to hand us a mere 64 bits on an architecture with 4-byte cache alignment > but is otherwise perfectly happy with 64-bit stores.
How about SNP_CACHE_BYTES or if less, then 32 bytes minimum? Or just stick with 64 bytes. Either way works for me.
-Ian
| |