Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ldms_record_heap_size() is confusing #1214

Open
morrone opened this issue Jun 14, 2023 · 3 comments
Open

ldms_record_heap_size() is confusing #1214

morrone opened this issue Jun 14, 2023 · 3 comments
Milestone

Comments

@morrone
Copy link
Collaborator

morrone commented Jun 14, 2023

The documentation (and maybe the function name) for ldms_record_heap_size() is confusing. Mostly I think the confusion arises because it only claims to "determines the memory size in the heap required for an instance of the given record". But looking at the code, that isn't true, it actually gives the size for both the record AND the storage for the list entry combined. That really needs to be clearly documented, because otherwise the list API is rather vague and confusing. I think that any competent developer is going to wonder where the list entry memory is coming from and be confused about how to grow and shrink the heap without that important detail.

We might also explicitly mention that records can only be used as part of lists (I assume that is true?) which would help to explain why the API doesn't give clean separate details for the list entry and record sizes separately.

@tom95858
Copy link
Collaborator

The ldms_list_append_item() and ldms_list_append_record() API both allocate the list entry as part of the allocation of the entry to be added. The functions return the ldms_mval_t for the allocated entity. The application gets the needed information from ldms_xxx_heap_size() function to get the size they need to provide to ldms_set_new_with_heap(). That said we don't have an interface called ldms_set_new_with_heap_and_auth() and so I'm bit confounded how we got here.

We need to schedule a UG meeting to walk through this and get an API together that is more cogent. Some ideas:

  • The heap list size can be reduced to list_max * sizeof(list_entry)
  • Currently anything that is allocated off the heap goes into a list. I don't see any other use case.
  • Ultimately, heaps will be exchanged in the monitoring infrastructure like sets are today...more to come here.
  • What to do when ldms_set_heap_alloc returns ENOMEM

Currently the code pattern is:

mval = ldms_list_append_item(list_handle, type, ...);
rc = ldms_mval_set_XXX(mval, <value>);

I would argue that this is preferred:

mval = ldms_set_heap_alloc(set, type, ...);
rc = ldms_mval_set_xxx(mval, <value>);
rc = ldms_list_append_item(..., type, mval);

For ldms_set_heap_alloc(), the var-arg list is empty for primitive types. For arrays, it would be the array length, and for records, it would be the metric-id for the record definition.

I would advocate for combining the ldms_list_append_item() and ldms_list_append_record() API into a single interface and deprecating ldms_list_append_record().

I think we should do this ASAP while these interfaces are exclusively used in our source base.

@tom95858
Copy link
Collaborator

@morrone, I agree we need to document this better. The whole point is to provide guidance to the developer on what they should specify as the heap-size when creating the metric set. Is this a 4.4.5 item?

@tom95858 tom95858 added this to the v4.5.1 milestone Oct 22, 2024
@morrone
Copy link
Collaborator Author

morrone commented Oct 22, 2024

It can wait.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants