[starpu-devel] Fw: Question about Properly Unregister Data for a Custom Interface

[Xinbo Li <lix34545@myumanitoba.ca>]

Sending this question to the mailing list for the record.

Thank you,

Xinbo

---

From: Xinbo Li
Sent: Tuesday, April 22, 2025 12:27 PM
To: Samuel Thibault
Subject: Re: Question about Properly Unregister Data for a Custom Interface

Hi Samuel, 

I do have an allocate_data_on_node method implemented as 

static starpu_ssize_t rkmatrix_allocate_data_on_node(void *data_interface, unsigned node)

{

    std::cout << "Allocate Data called.\n";

    struct starpu_rkmatrix_interface *rkmatrix_interface =

        (struct starpu_rkmatrix_interface *) data_interface;

    // prkmatrix rkmat = rkmatrix_interface->rkmat;

    /* Allocate memory for the rkmatrix struct */

    prkmatrix rkmat_new = NULL;

    double *a_real = NULL; double *a_imag = NULL;

    double *b_real = NULL; double *b_imag = NULL;

    starpu_ssize_t requested_memory_a = 0, requested_memory_b = 0;

    starpu_ssize_t rk_struct_size = sizeof(rkmatrix);

    rkmat_new = (prkmatrix) starpu_malloc_on_node(node, rk_struct_size); // a new rkmatrix pointer

    if (!rkmat_new)

        goto failure;

    *rkmat_new = *rkmatrix_interface->rkmat; // copy the meta data (data pointers will also be

    // copied but will be reset shortly)

    rkmatrix_interface->rkmat = rkmat_new;

    /* Allocate memory for the data members in rkmat */

    requested_memory_a = rkmatrix_interface->rkmat->rows * rkmatrix_interface->rkmat->k * sizeof(rkmatrix_interface->rkmat->a[0]);

    requested_memory_b = rkmatrix_interface->rkmat->cols * rkmatrix_interface->rkmat->k * sizeof(rkmatrix_interface->rkmat->b[0]);

    a_real = (double*) starpu_malloc_on_node(node, requested_memory_a);

    if (!a_real)

        goto failure;

    a_imag = (double*) starpu_malloc_on_node(node, requested_memory_a);

    if (!a_imag)

        goto failure;

    b_real = (double*) starpu_malloc_on_node(node, requested_memory_b);

    if (!b_real)

        goto failure;

    b_imag = (double*) starpu_malloc_on_node(node, requested_memory_b);

    if (!b_imag)

        goto failure;

   

    /* update the data properly in consequence */

    rkmatrix_interface->rkmat->a = a_real;

    rkmatrix_interface->rkmat->a_imag = a_imag;

    rkmatrix_interface->rkmat->b = b_real;

    rkmatrix_interface->rkmat->b_imag = b_imag;

    return 2*(requested_memory_a+requested_memory_b) + rk_struct_size;

failure:

    return -ENOMEM;

}

Would this method be called on the nodes who do not have the data after the registration somehow? That is why I free memory in the unregistration.

Also, the reason I implemented an unregistration method and called it explicitly is because calling starpu_data_unregister will always seg fault for some reason, so I thought it might be easier to have a explicit call to the unregistration method.

Thank you,

Xinbo 

---

From: Samuel Thibault <samuel.thibault@inria.fr>
Sent: Tuesday, April 22, 2025 12:16 PM
To: Xinbo Li <lix34545@myumanitoba.ca>
Subject: Re: Question about Properly Unregister Data for a Custom Interface

 

Caution! This message was sent from outside the University of Manitoba.


Xinbo Li, le mar. 22 avril 2025 19:15:07 +0000, a ecrit:
> By the way, my registration is added here for reference:
> static void rkmatrix_register_data_handle(
>     starpu_data_handle_t handle, int home_node, void *data_interface)
> {
>     struct starpu_rkmatrix_interface *rkmatrix_interface =
>         (struct starpu_rkmatrix_interface *) data_interface;
>
>     int node;
>     for (node = 0; node < STARPU_MAXNODES; node++)
>     {
>         struct starpu_rkmatrix_interface *local_interface =
>             (struct starpu_rkmatrix_interface *)
> starpu_data_get_interface_on_node(handle, node);
>
>         if (node == home_node)
>         {
>             local_interface->rkmat = rkmatrix_interface->rkmat;
>         }
>         else
>         {
>             local_interface->rkmat = NULL;
>         }
>     }

So you're not allocating anything there. So you shouldn't release
anything on unregistration.

Samuel