Allow user-data for chunks.

[ldalessa]

We use the custom chunk allocators to manage network-registered memory. A network-registration event returns a "key" that must be used with future network DMA operations. Right now, we store these keys out-of-place and look them up as necessary.

It would be really convenient for us if we could store the key (16 bytes at the moment) as part of the jemalloc chunk metadata at the base of each chunk or out-of-place for large allocations, and retrieve it using jemalloc's fast internal address masking or lookup.

An interface like id = JE_CURRENT_CHUNK(), je_chunk_set_user_data(chunk_id id, void *data, size_t size), and void *je_chunk_get_user_data(chunk_id id) would save us a lot of work for tracking this information.

A bounded size for user data would be fine.

This is simply a feature request to go along with the custom chunk allocation infrastructure.

[jasone]

I have some similar hypothetical use cases involving garbage collector metadata. One challenge for the application is that huge allocations still have to be handled similarly to your current approach.

As for implementation challenges, the messiest one I'm aware of is that we either have to know how large the application metadata will be during allocator bootstrapping, or we have to track how much metadata actually got allocated on a per chunk basis (assuming that some chunks may have been created prior to application metadata being configured).

One other consideration is whether to put application metadata in the chunk header, or to instead create a separate chunk footer. I slightly favor the chunk footer at the moment, because it enables simpler math for locating the metadata, which might be critical to performance in e.g. a GC write barrier.

[jasone]

The GC use case allows the application metadata to be proportional to the allocation size. So, a page of 16-byte regions would have the same amount of metadata storage as a page of 32-byte regions. Does that fit with your use case?

[ldalessa]

We really only need one fixed-width value per chunk. I can't, at the moment, think of a reason that we'd need anything dependent on the actual data. I just need to supply it to the network driver whenever anyone tries to perform DMA from or to the chunk.

I have no preference w.r.t. header or footer that I can think of.

[ldalessa]

Oops, wrong button, sorry.

[jasone]

Embedding this in the header is probably better for small metadata uses like yours because it doesn't automatically require a full page to satisfy.

[ldalessa]

Yeah, as long as I can uniformly find it that's okay. I don't precisely know how jemalloc finds the larger allocations—there's clearly not a header being used there since we're getting the 0-bit offset back for them (which is good because we often need that alignment).

[DmitryKiselev]

Hi there,
We are also working with network registered memory and custom chunk allocators.

Although, with RDMA sometimes you just want to expose a whole memory region for direct remote access (e.g. remote reads). (Memcached double read technique does just that).

Hence, I would propose not to reserve that extra header or footer in a memory chunk by default. In other words if je_chunk_set_user_data() is not called, the whole chunk should be available to a user.

[ldalessa]

Hi Dmitry. My understanding is that, for normal chunks, jemalloc always uses a header for its own purpose, so the entire chunk would never be available. For "large" allocations I think jemalloc uses out-of-place metadata (or chunk footers?) to store its information. I'm sure Jason can elaborate.

[thestinger]

Chunks (4M before, 256k recently in master) are naturally aligned and it finds the header where metadata is stored from the alignment offset. Anything at least as large as the chunk size (jemalloc calls these "huge") uses a global data structure for the metadata.

[ldalessa]

Oh, that's the first time I heard about the 256k change. 256k is a terrible chunk size for applications that are using common hugetlb sizes. I know chunk size can be set in MALLOC_CONF and via explicit char * string symbols, but that's sort of brittle.

I'll have to add a request for jemalloc to use the hugetlbfs default page size for default chunk size if it exists and isn't overriden by MALLOC_CONF.

[thestinger]

I like the idea of 2M as the default chunk size because it makes chunk/huge allocation play very well with transparent huge pages. I think there are good reasons for jemalloc switching to 256k though. The page fault heuristic for transparent huge pages also plays very poorly with jemalloc and tcmalloc right now but I don't really expect chunks smaller than 2M to result in less huge pages in the long term. It would need to be measured.

[thestinger]

I think it switched to 256k because it reduces metadata overhead caused by sparsely filled chunks left after many deallocations but that are not completely emptied.