[lkml]   [2007]   [Nov]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC v2] Documentation about unaligned memory access
    On Thu, 29 Nov 2007 16:15:23 +0000 (GMT) Daniel Drake wrote:

    > Assuming there aren't too many comments/suggestions on this revision, the
    > next version will be submitted for inclusion as
    > Documentation/unaligned_memory_access.txt

    I just have a few typo/punctuation/grammar fixes. Otherwise it looks
    good to me. Thanks.

    Acked-by: Randy Dunlap <>

    > Natural alignment
    > =================
    > The rule mentioned above forms what we refer to as natural alignment:
    > When accessing N bytes of memory, the base memory address must be evenly
    > divisible by N, i.e. addr % N == 0

    add ending '.'

    > Why unaligned access is bad
    > ===========================
    > The effects of performing an unaligned memory access vary from architecture
    > to architecture. It would be easy to write a whole document on the differences
    > here; a summary of the common scenarios is presented below:
    > - Some architectures are able to transparently perform unaligned memory
    > accesses, but there is usually a significant performance cost.

    (remove split infinitive:)

    - Some architecture are able to perform unaligned memory accesses
    transparently, but ...

    > - Some architectures raise processor exceptions when unaligned accesses
    > happen. The exception handler is able to correct the unaligned access,
    > at significant cost to performance.
    > - Some architectures raise processor exceptions when unaligned accesses
    > happen, but the exceptions do not contain enough information for the
    > unaligned access to be corrected.
    > - Some architectures are not capable of unaligned memory access, but will
    > silently perform a different memory access to the one that was requested,
    > resulting a a subtle code bug that is hard to detect!
    > It should be obvious from the above that if your code causes unaligned
    > memory accesses to happen, your code will not work correctly on certain
    > platforms and will cause performance problems on others.

    > Code that causes unaligned access
    > =================================
    > With the above in mind, let's move onto a real life example of a function
    > that can cause an unaligned memory access. The following function adapted
    > from include/linux/etherdevice.h is an optimized routine to compare two
    > ethernet MAC addresses for equality.
    > unsigned int compare_ether_addr(const u8 *addr1, const u8 *addr2)
    > {
    > const u16 *a = (const u16 *) addr1;
    > const u16 *b = (const u16 *) addr2;
    > return ((a[0] ^ b[0]) | (a[1] ^ b[1]) | (a[2] ^ b[2])) != 0;
    > }
    > In the above function, the reference to a[0] causes 2 bytes (16 bits) to
    > be read from memory starting at address addr1. Think about what would happen
    > if addr1 was an odd address such as 0x10003. (Hint: it'd be an unaligned
    > access)


    > Avoiding unaligned accesses
    > ===========================
    > The easiest way to avoid unaligned access is to use the get_unaligned() and
    > put_unaligned() macros provided by the <asm/unaligned.h> header file.
    > Going back to an earlier example of code that potentially causes unaligned
    > access:
    > void myfunc(u8 *data, u32 value)
    > {
    > [...]
    > *((u32 *) data) = cpu_to_le32(value);
    > [...]
    > }
    > To avoid the unaligned memory access, you would rewrite it as follows:
    > void myfunc(u8 *data, u32 value)
    > {
    > [...]
    > value = cpu_to_le32(value);
    > put_unaligned(value, data);
    > [...]
    > }
    > The get_unaligned() macro works similarly. Assuming 'data' is a pointer to
    > memory and you wish to avoid unaligned access, its usage is as follows:
    > u32 value = get_unaligned(data);
    > These macros work work for memory accesses of any length (not just 32 bits as
    > in the examples above). Be aware that when compared to standard access of
    > aligned memory, using these macros to access unaligned memory can be costy in


    > terms of performance.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-11-29 18:53    [W:0.026 / U:14.612 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site