hi, > -----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 ;-)
we loose the flexibility of the implementation. > 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. i guess page-alignment and cache-line-alignemnt should be considered separately. i currently have no idea how many of kmem_alloc users are sensitive to cache-line-alignment. YAMAMOTO Takashi > > 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-----
