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/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.

Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


Home | Main Index | Thread Index | Old Index