Re: kmem-pool-uvm

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

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

On 06/12/11 11:55, Lars Heidieker wrote:
> 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

and having cache-line-size alignment, should yield better performance
especially on SMP because of cache-line sharing effects...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEUEARECAAYFAk30p28ACgkQcxuYqjT7GRaU9QCfR6/as/mGPmSg6mSHarBYL4EZ
QUcAl0tI03B2MVmTAS7RsDz5jYBq8Fk=
=OGyo
-----END PGP SIGNATURE-----