[ snipped...]

Looking at the ::kmem_cache output:

32-bit:

cac2e2b0 streams_dblk_1984 020f 000000 2048 9

64-bit

ffffffffec0033c08 streams_dblk_1936 0269 000000 2048 602

The third field is the "flags" field; this contains the full reason for all the differences you noticed.

32-bit: KMF_HASH | KMF_CONTENTS | KMF_AUDIT | KMF_DEADBEEF | KMF_REDZONE 64-bit: KMF_HASH | KMF_CONTENTS | KMF_AUDIT | KMF_FIREWALL | KMF_NOMAGAZINE

The flags they both have are KMF_HASH (buffers require a hash table to track control structures), KMF_CONTENTS (record contents of buffer upon free), KMF_AUDIT (record information about each allocation and free).

The 64-bit cache is a firewall cache; this means the buffer size is rounded up to a multiple of PAGESIZE, and all buffers are allocated so that the end of the buffer is at the end of a page. The allocation is then done in such a way that there is an unmapped VA hole *after* that page, and so that allocation addresses are not re-used recently. The magazine (that is, caching) layer of the cache is disabled, which means that the objects are freed and unmapped immediately upon kmem_cache_free().

The 32-bit cache is a standard debugging cache; the slabs are five pages long, which is 9 buffers / slab (0x5000 / 0x540); the extra 40 bytes is a "REDZONE", used to detect buffer overruns, etc. The magazine layer is *enabled*, which means that freed buffers are cached, until the system notices that we're running low on space.

The difference only exists on DEBUG kernels, and is because firewalling is not done on 32-bit platforms, since the allocation patterns used waste and fragment VA space.

On a non-debug system, the setup will be pretty much the same between 32-bit and 64-bit systems.