[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.066 / U:1.868 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site