Re: [PATCH v4 08/23] ewah: compressed bitmap implementation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jan 23, 2014 at 03:26:45PM -0500, Jeff King wrote:
> Looking over the format, I think the only thing preventing 4-byte
> alignment is the 1-byte XOR-offset and 1-byte flags field for each
> bitmap. If we ever have a v2, we could pad the sum of those out to 4
> bytes. Is 4-byte alignment enough? We do treat the actual data as 64-bit
> integers. I wonder if that would have problems on Sparc64, for example.

Yes, it will.  SPARC requires all loads be naturally aligned (4-byte to
an address that's a multiple of 4, 8-byte to a multiple of 8, and so
on).  In general, architectures that do not support unaligned access
require natural alignment for all quantities.

Also, even on architectures where the kernel can fix these alignment
issues up, the cost of doing so is a two context switches (in and out of
the kernel), servicing the trap, two loads, some shifts and rotates, and
a kernel message, so many people disable alignment fixups.  I know it
made things extremely slow on Alpha.  ARM is even more fun since if you
don't take the trap, it loads the data rotated, so the load happens, it
just silently returns the wrong data.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187

Attachment: signature.asc
Description: Digital signature


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]