linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Matt Mackall <mpm@selenic.com>
To: Ian Molton <ian.molton@collabora.co.uk>
Cc: Rusty Russell <rusty@rustcorp.com.au>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] hw_random: core updates to allow more efficient drivers
Date: Mon, 30 Nov 2009 12:44:16 -0600	[thread overview]
Message-ID: <1259606656.29740.48.camel@calx> (raw)
In-Reply-To: <4B139E3D.1020905@collabora.co.uk>

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.

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-). 

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. 

-- 
http://selenic.com : development and support for Mercurial and Linux



  reply	other threads:[~2009-11-30 18:45 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <4B080621.5000109@collabora.co.uk>
     [not found] ` <4B0C18B0.2000206@collabora.co.uk>
     [not found]   ` <1259084901.17871.624.camel@calx>
     [not found]     ` <200911251135.41871.rusty@rustcorp.com.au>
     [not found]       ` <4B0D03FC.40406@collabora.co.uk>
2009-11-25 19:27         ` hw_random fixes Matt Mackall
2009-11-25 20:43           ` Ian Molton
2009-11-26  0:25           ` Ian Molton
2009-11-26  0:25             ` [PATCH 1/2] hw_random: core updates to allow more efficient drivers Ian Molton
2009-11-26  0:25               ` [PATCH 2/2] virtio: Convert virtio-rng to the new API Ian Molton
2009-11-28 10:00                 ` Rusty Russell
2009-11-30  9:55                   ` Ian Molton
2009-11-26  1:03               ` [PATCH 1/2] hw_random: core updates to allow more efficient drivers Matt Mackall
2009-11-26 10:49                 ` Ian Molton
2009-11-26 10:49                   ` [PATCH 1/2] hw_random: core updates to allow more efficient drivers Ian Molton
2009-11-26 11:38                   ` Matt Mackall
2009-11-26 11:48                     ` Re: Ian Molton
2009-11-27 22:54                       ` Re: Matt Mackall
2009-11-28  0:51                         ` rng updates Ian Molton
2009-11-28 10:05                 ` [PATCH 1/2] hw_random: core updates to allow more efficient drivers Rusty Russell
2009-11-30 10:28                   ` Ian Molton
2009-11-30 18:44                     ` Matt Mackall [this message]
2009-12-01  3:08                       ` Rusty Russell
2009-12-01  9:23                         ` Ian Molton
2009-12-01  9:18                       ` Ian Molton
2009-11-26  3:12               ` Jeff Garzik
2009-11-26  0:44           ` Ian Molton
2009-11-26  0:44             ` [PATCH 1/2] hw_random: core updates to allow more efficient drivers Ian Molton
2009-11-26  0:44               ` [PATCH 2/2] virtio: Convert virtio-rng to the new API Ian Molton
2009-11-30 10:38                 ` hw_random update Ian Molton
2009-11-30 10:38                   ` [PATCH 1/2] hw_random: core updates to allow more efficient drivers Ian Molton
2009-11-30 10:38                     ` [PATCH 2/2] virtio: Convert virtio-rng to the new API Ian Molton
2009-12-01  7:27                       ` Herbert Xu
2009-12-01  9:29                         ` Ian Molton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1259606656.29740.48.camel@calx \
    --to=mpm@selenic.com \
    --cc=ian.molton@collabora.co.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rusty@rustcorp.com.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).