mm.c 中定义了内存池的起始地址,是 24M
#define PHYSICAL_MEM_START (24 * 1024 * 1024) // 24M
#define START_VADDR phys_to_virt(PHYSICAL_MEM_START) // 24M
那么对于 order 为 11 的第一个内存块 0xffffff0001800000,按照 buddy.c 中初始的 get_buddy_chunk 逻辑,计算得到的它的 buddy chunk 地址为 0xffffff0001000000, 但是这个 chunk 并不是当前情况下我们想要找到的 buddy chunk,实际的 buddy 为 ffffff0001800000 + 800000
order=11 的块大小为 8M,24 不是 8 的偶数倍,因此产生了这个问题。如果修改 get_buddy_chunk 的逻辑就不能直接通过为运算得到 buddy 了。

get_buddy_chunk的逻辑是没有问题的
START_VADDR 以下的内存并没有被加入到pool
建议仔细看下 kernel/mm/mm.c 的 mm_init 函数 和 kernel/mm/buddy.c 的 init_buddy 函数

    huangzheng 我仔细看了一下,我发现的问题是以24M为起始地址,0xffffff0001800000的 11 阶 buddy 应该是 0xffffff0002000000。使用这个 get_buddy_chunk 逻辑应该对整块内存的起始地址有要求,24M不满足这个要求,因此算出的 buddy chunk (0xffffff0001000000)不是我所预期的

    ”24M为起始地址“意思是只有这些地址以上的内存在init_buddy时被加入到了buddy,与buddy的地址计算没有任何关系,buddy的地址计算仍然从0开始
    例如,0阶buddy的第一个块的虚拟地址仍然是0xffffff0000000000,只是因为init_buddy时没有把这个块加进去,所以不会被分配出来

      Write a Reply...