Re: kmem-pool-uvm

[Lars Heidieker <lars%heidieker.de@localhost>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/09/11 01:44, Mindaugas Rasiukevicius wrote:
> yamt%mwd.biglobe.ne.jp@localhost (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-----