tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: kmem-pool-uvm

Hash: SHA1

On 06/12/11 11:55, Lars Heidieker wrote:
> On 06/09/11 01:44, Mindaugas Rasiukevicius wrote:
>> (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...
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


Home | Main Index | Thread Index | Old Index