-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/09/11 01:44, Mindaugas Rasiukevicius wrote: > [email protected] (YAMAMOTO Takashi) wrote: >>> Yes it does, it switches to cache_line size for alignment for >>> allocations >= cache_line size and to page_size alignment for >>> allocations >= page_size. >> >> kmem_alloc(9F) says: >> >> The allocated memory is at least double-word aligned, so it can >> hold any C data structure. No greater alignment can be >> assumed. >> >> % uname -sr >> SunOS 5.10 >> >> so i don't think it's api-wise guaranteed. >> IMO it's better to use a low-level allocator (eg. uvm_km_alloc) for >> alignment-sensitive users. > > While for page-size alignment, it makes sense to use uvm_km(9) allocator, > there are quite a few allocations when it is useful to give a separate > cache-line for a structure. I am not sure if it is desirable to sprinkle > pad & align magic each time in the caller's side, instead of adding such > support to kmem(9). Perhaps kmem_cacheline_{alloc,free}? >
It's not api-wise guaranteed, but what do we loose if we get those alignments? Nothing I think, they are in place with the OpenSolaris implementation as well ;-) I don't think it's a good idea to have a different api for cache-line-aligned memory, this would require different pools for cache-size-aligned memory and not cache-line-aligned memory just spreading out the allocations and increasing fragmentation. If the kva is controlled by a vmem arena then those page-size aligned allocation should go to that arena, which quantum is page-size anyway. Lars -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk30jQQACgkQcxuYqjT7GRYGHgCdErYJzFuB6sM5iJlucc/GO51r r+8AnA5QjSfnKsB1+44DQQtJ7osS8e5w =whHX -----END PGP SIGNATURE-----
