#Understanding memory allocation with mmap.

16 messages · Page 1 of 1 (latest)

tender apex
#

Hello, I am working on a slab allocator for a school project.

I got to the point of getting a memory zone, the size of that memory zone is a multiple of sysconf(_SC_PAGESIZE).

    t_zone  *new_zone;
    new_zone = mmap(NULL, size, PROT_READ | PROT_WRITE, \
                    MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
    if (new_zone == MAP_FAILED)
    {
        ft_putstr_fd("mmap() returned MAP_FAILED\n", 2);
        return NULL;
    }
    int test = alignof(t_zone);
    (void)test;
    ft_memset(new_zone, 0, sizeof(t_zone));
    new_zone->size_total = size;
    new_zone->size_available = size - sizeof(t_zone);
    add_page_to_global(size, new_zone, *zones);
    return new_zone;

With s_zone :

struct s_zone {
    t_zone *prev;
    t_zone *next;
    size_t  size_total;
    size_t  size_available;
    t_block *blocks;
};

What I don't get is, where can I actually start storing data ? and where my first block of "user data" should be in this. I have this little drawing I made that I think is how it is represented.
.

Capture_decran_2025-02-05_155446.png
flint patioBOT
#

When your question is answered use !solved to mark the question as resolved.

Remember to ask specific questions, provide necessary details, and reduce your question to its simplest form. For tips on how to ask a good question use !howto ask.

tender apex
#

And people have tried explaining it to me already, in #c-help-text but I think it is smarter for me to make a thread about my problem so I can come back to the explanation.

lofty sparrow
#

You have 2 choices, either:

  • store it in the same region you got from mmap beside your user data
  • or store it somewhere else
tender apex
lofty sparrow
#

Your drawing there suggest you want to store it beside your user data, meaning the region you got as a result from your mmap call can be thought of a sequence of 'blocks'. Each block will have a header (or a footer, whatever you prefer) in which your allocator will store the block metadata.
The allocator will then return a pointer pointing past the header (assuming header here) to the user to store its data in

tender apex
#

Yes ! The thing is, I know I need to have that header, but I don't know why I need it... If you know where I could learn why there is a header ? ACTUALLY, I turned on my brain, i of course need it to store the remaining size of the zone or the size of the block or if the block is free.

However I meant to ask, how can I "store" that ?
The header of a block for exemple should be big enough to fit :

  • ptr * 2
  • size_t * 1
  • bool * 1
  • memory aligment
    ?
    And then after that I can store the actual user data
#

and all this data (header + user data) should fit in a block ?

lofty sparrow
tender apex
#

Sorry this is the struct of an element block :

struct s_block {
    t_block *prev;
    t_block *next;
    size_t  size;
    bool    free;
};
lofty sparrow
#

how can i store that
You just find a big enough block (for your header + user requested size) you write your metadata into it and give the user a pointer to the region past your metadata

tender apex
#

OK.

lofty sparrow
tender apex
#

Then a question comes to mind.
I know how to manipulate an array of char with dynamically allocated memory. However, if I want to write the metadata lets say write a size_t size element in that header space I reserved. How would I do that ?

#

Because I cant just say addr->size = size ?

lofty sparrow
#

You generally want to memcpy a t_block into the block (in order to avoid effective type problems which may come from a cast)