rcore-os / buddy_system_allocator

A buddy system allocator in pure Rust.

buddy_system_allocator

An (almost) drop-in replacement for phil-opp/linked-list-allocator. But it uses buddy system instead.

Usage

To use buddy_system_allocator for global allocator:

use buddy_system_allocator::LockedHeap;

#[global_allocator]
static HEAP_ALLOCATOR: LockedHeap = LockedHeap::<32>::empty();

To init the allocator:

unsafe {
    HEAP_ALLOCATOR.lock().init(heap_start, heap_size);
    // or
    HEAP_ALLOCATOR.lock().add_to_heap(heap_start, heap_end);
}

You can also use FrameAllocator and LockedHeapWithRescue, see their documentation for usage.

Features

• use_spin (default): Provide a LockedHeap type that implements the GlobalAlloc trait by using a spinlock.
• const_fn (nightly only): Provide const fn version of LockedHeapWithRescue::new.

License

Some code comes from phil-opp's linked-list-allocator.

Licensed under MIT License. Thanks phill-opp's linked-list-allocator for inspirations and interface.

buddy_system_allocator's Issues

Failure when use buddy_system_allocator

Hello! I'm playing around with buddy_system_allocator and have a minimal hello-world program, which I thought should work:

use buddy_system_allocator::LockedHeap;
use libc;
use core::ptr;
fn main() {

    #[global_allocator]
    static GLOBAL: LockedHeap::<32> = LockedHeap::<32>::empty();
    
    let address: *mut libc::c_void;
    unsafe {
        address = libc::mmap(ptr::null_mut(), 1<<29 as usize, libc::PROT_READ | libc::PROT_WRITE,
        libc::MAP_PRIVATE | libc::MAP_ANON, -1, 0);
    }
    if address == libc::MAP_FAILED {
        panic!("mmap: failed to get mapped memory area for heap");
    }
    unsafe {
        GLOBAL.lock().init(address as usize, 1<<29 as usize);
    }
    println!("Hello, world!");
}

This fails with message

memory allocation of 4 bytes failed
Aborted (core dumped)

Can you kindly point out what's the issue with my code?

Thanks very much

AllocRef API 更新导致无法编译

rust-lang/rust@d8e3557#diff-1b08d266cc36e37196b43a2251a5392b

3 月 3 日的一次 commit 中将 alloc realloc 和 alloc_zeroed 的返回类型从 Result<NonNull<u8>, AllocErr> 变为 Result<(NonNull<u8>, usize), AllocErr>，额外返回了 layout.size()

关于伙伴分配的数据结构

pub struct FrameAllocator {
// buddy system with max order of 32
free_list: [BTreeSet; 32],

// statistics
allocated: usize,
total: usize,

}

为什么free_list要选择BTreeSet？谢谢

Is it possible to add fixed address allocation for `FrameAllocator`

Some times we need to allocate space at fixed address. I hope we can support for that

Allow alignment to be specified for `FrameAllocator`

For some usecases, e.g. allocating MMIO space for PCI BARs, it is necessary to allocate address space with both a particular size and a particular alignment. It would be useful if FrameAllocator::alloc took an alignment parameter to specify what alignment is required.

index out of bounds: the len is 30 but the index is 30

There is a bug in lib.rs between L158 to L 178.

Provide the ORDER is 30. If the current_class is 29, i.e. the last index, the L174 will get error "Index out of bounds".

        while current_class < self.free_list.len() {
            let buddy = current_ptr ^ (1 << current_class);
            let mut flag = false;
            for block in self.free_list[current_class].iter_mut() {
                if block.value() as usize == buddy {
                    block.pop();
                    flag = true;
                    break;
                }
            }

            // Free buddy found
            if flag {
                self.free_list[current_class].pop();
                current_ptr = min(current_ptr, buddy);
                current_class += 1;
                self.free_list[current_class].push(current_ptr as *mut usize);
            } else {
                break;
            }
        }

Support Basic Statistics

We need some statistical information to profile our system.
For example: used memory, available memory, and other internal parameters...

The implementation dose not guarantee O(logN)

lib.rs::Heap::dealloc is not O(logN)
You may use something like a bitmap to check if the buddy page is free or not.

Bump dependency version

spin is 0.7.0 now.

Allocation spuriously fails

I got a spurious allocation failure even when there is enough space.

The flow is:

1. An area of X bytes (8-bytes aligned) is used to initialize the buddy system allocator.
2. At the very start of kernel initialization, right after init_heap, I try to allocate X bytes with

let g = alloc::boxed::Box::new([0u8; KERNEL_HEAP_SIZE]);

3. The kernel reports a heap allocation error.

The problem disappears if I switch to linked_list_allocator.

Is there any caveat for using this allocator?

using the crate of version "0.9" meeting the error about using unstabele api

When i learning the rcore in windows platform, i use this crate with version 0.9, instead of the version in tutorial is 0.6. I meet the error

and here is the code lab in this commit:
https://github.com/kyrosle/OS/tree/ccb88e0819c230fa53df1cc2993f05c5eab9fcd3

Only using 0.9 will cause this error, but 0.8 seem all right.

missing generics for struct `LockedHeap`

#[global_allocator]
static HEAP_ALLOCATOR: LockedHeap = LockedHeap::empty();

I use 0.8.0 version. And it reports that "missing generics for struct LockedHeap
expected 1 const argumen"

Order 32 is restricting for 64 bit machines

Order 32 of the linked list allows about a 4GB of heap for any process. This can easily be crossed when the crate is used under a 64 bit Virtual Space which can address upto 48 bits of information.

Please provide a larger order or an option to increase the order