On Tue, Dec 02, 2014 at 03:28:17PM -0500, George Spelvin wrote: > >> --- a/crypto/ansi_cprng.c > >> +++ b/crypto/ansi_cprng.c > >> @@ -51,9 +51,9 @@ struct prng_context { > >> unsigned char rand_data[DEFAULT_BLK_SZ]; > >> unsigned char DT[DEFAULT_BLK_SZ]; > >> unsigned char V[DEFAULT_BLK_SZ]; > >> - u32 rand_read_pos; /* Offset into rand_data[] */ > >> + unsigned char rand_read_pos; /* Offset into rand_data[] */ > > > u8 please. Also, not sure if this helps much, as I think the padding > > will just get you back to word alignment on each of these. > > I noticed the "unsigned char" vs "u8" issue, but didn't make the change > as I didn't think the readailility improvement was worth the code churn. > You just sent a 17 patch series of clean up and were worried about code churn converting an unsigned char to a u8? > But I'd be happy to clean that up, too! > > Should I convert all the buffers and function prototypes, or is there > some criterion for distinguishing which gets which? (E.g. buffers are > "unsigned char" but control variables are "u8".) > If you want to sure. u8 probably makes more sense for the buffers here as our intent is to treat them as an array of byte values. > And actually, you do win. spinlock_t is 16 bits on x86, > and the buffers are all 16 bytes. (80 bytes before my earlier > patches, 48 bytes after.) > > So the the structure goes from: > > 32-bit 64-bit Variable > Offset Size Offset Size > 0 2 0 2 spinlock_t prng_lock > 2 16 2 16 unsigned char rand_data[16] > 18 16 18 16 unsigned char DT[16] > 34 16 34 16 unsigned char V[16] > 50 2 50 2 (alignemnt) > 52 4 52 4 u32 rand_read_pos > 56 4 56 8 struct crypto_cipher *tfm > 60 4 64 4 u32 flags > 68 4 (alignment) > 64 72 (structure size) > > to > > 32-bit 64-bit Variable > Offset Size Offset Size > 34 16 34 16 unsigned char V[16] > 50 1 50 1 u8 rand_read_pos > 51 1 51 1 u8 flags > 52 4 (alignment) > 52 4 56 8 struct crypto_cipher *tfm > 56 64 (structure size) > > You still get 4 bytes of alignment padding on x86-64, but given that > the structure has 60 bytes of payload, that's the minimum possible. > > You save 6 bytes of variables and 2 bytes of padding on both > 32- and 64-bit systems, for a total of 8 bytes, and that's enough > to knock you into a smaller slab object bin on 64-bit. > > > I forget where I read the terminology, but the most efficient > wat to pack a structure is in an "organ pipe" configuraiton where > the biggest (in terms of *alignment*) members are on the outside > and the structre and the smaller elements are on the inside. > Putting a 32-bit "flags" after a 64-bit pointer violates that. > -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html