mm: Add pending configuration for mm node struct and precding

[W-M-R]

pending memory block node precding and the entire struct, after turning on this bit, the size of each memory block wil be aligned to MM_ALIGN

Note: Please adhere to Contributing Guidelines.

Summary

pending memory block node precding and the entire struct, after turning on this bit, the size of each memory block wil be aligned to MM_ALIGN.Adding this alignment can solve this problem

Impact

The new feature arm64 MTE is added, "#15461" requires that the allocated block address must be 16-byte aligned and the size must also be 16-byte aligned. Our current memory management does not meet the requirements.

Testing

Update this section with details on how did you verify the change,
what Host was used for build (OS, CPU, compiler, ..), what Target was
used for verification (arch, board:config, ..), etc. Providing build
and runtime logs from before and after change is highly appreciated.

[nuttxpr]

[Experimental Bot, please feedback here]

This PR does not fully meet the NuttX requirements yet. While it provides a basic description of the change, it lacks crucial details in the Impact and Testing sections.

Here's a breakdown of what's missing:

• Summary: While it describes what is changed, it's missing why. What problem does aligning memory blocks to MM_ALIGN solve? Is this a performance optimization, a bug fix, or something else? It needs more context. Mention any related issues.

• Impact: This section is essentially empty. It needs to be filled out completely. Consider the following:

  • Is this a new feature? If so, explicitly state that.
  • User Impact: Will users need to change any configuration options? Will existing applications break?
  • Build Impact: Will users need to change anything in their build system?
  • Hardware Impact: Does this change affect specific architectures or boards?
  • Documentation Impact: Does the documentation need to be updated to reflect this change? If so, has the documentation been updated in this PR or another?
  • Security Impact: Are there any potential security implications of this change? Even if the answer is no, explicitly state that.
  • Compatibility Impact: Does this change break backwards compatibility?

• Testing: This section is also largely empty. It needs concrete details:

  • Build Host: Specify the operating system, CPU architecture, and compiler version used. (e.g., "Linux x86_64, GCC 12.1")
  • Target: Specify the architecture and board/configuration tested. (e.g., "sim:qemu-arm")
  • Logs: Provide actual logs from before and after the change. These logs should demonstrate that the change has the intended effect. Show how memory allocation behaves differently now. Don't just leave the placeholder text.

In short, the PR needs to be significantly more detailed before it can be properly reviewed. Filling in the missing information in the Impact and Testing sections is crucial. The Summary section could also benefit from more context.

[yamt]

what are you trying to fix with this?

[W-M-R]

what are you trying to fix with this?

The new feature arm64 MTE is added, "#15461" requires that the allocated block address must be 16-byte aligned and the size must also be 16-byte aligned. Our current memory management does not meet the requirements.Adding this alignment can solve this problem

[xiaoxiang781216]

why not simplify to:

mmsize_t preceding aligned_data(MM_ALIGN);

[W-M-R]

It is invalid to do aligned_data(MM_ALIGN) on precding alone.

#include <stdio.h>


struct st0
{
    char a;
    char b;
}__attribute__((aligned(16)));

struct st1
{
    char a __attribute__((aligned(16)));
    char b;
};

struct st2
{
    char a;
    char b __attribute__((aligned(16)));
};

struct st3
{
    char a __attribute__((aligned(16)));
    char b __attribute__((aligned(16)));
    char d[15];
}__attribute__((aligned(16)));

struct st4
{
    union
    {
        char a;
        char a_align[16];
    };

    union
    {
        char b;
        char b_align[16];
    };
};

#define OFFSET(struct, member) (&(((struct *)0)->member))

#define PRINTF_STRUCT(struct) \
    printf("%s: ", #struct); \
    printf("size: %d\n", sizeof(struct)); \
    printf("member a: %d\n", OFFSET(struct, a)); \
    printf("member b: %d\n", OFFSET(struct, b));

int main()
{
    PRINTF_STRUCT(struct st0);
    PRINTF_STRUCT(struct st1);
    PRINTF_STRUCT(struct st2);
    PRINTF_STRUCT(struct st3);
    PRINTF_STRUCT(struct st4);
}

struct st0: size: 16
member a: 0
member b: 1
struct st1: size: 16
member a: 0
member b: 1
struct st2: size: 32
member a: 0
member b: 16
struct st3: size: 32
member a: 0
member b: 16
struct st4: size: 32
member a: 0
member b: 16

My understanding is that the alignment of attribute((aligned(16))) is more about the alignment of the size of the entire structure, and the alignment of a single member is limited to the alignment of access, not size.Therefore, using union is the only effective way to align the size

[xiaoxiang781216]

why need

[W-M-R]

The ptr that the user gets is the size of our node plus the size of the entire result body, so the entire structure must also be aligned