0

I'm confused about whether the memory allocated by Linux when a process requests 'x' amount of heap is actually contiguous physically or not?

Here's my understanding till now: The unit of memory allocation in Linux is page size. By default, page size = 4KB. The page is physically contiguous in RAM.

As seen from the output of /proc/buddyinfo, the total memory is divided into several groups group 0, group 1, ... group 10

Each group 'n' contains multiple physically contiguous pages of memory, each of size 4KB * (2^n)

so group 0 contains pages of size 4KB, group 1 contains pages of size 8KB, group 2 contains pages of size 16KB etc.

now if suppose an application requests 12 KB of memory and suppose from group 2 onwards there is no free page available.

I want to know

  1. whether memory allocation request will be successful in this case by using 1 page each from group 0 and group 1? or will it fail?

  2. Are the pages in a particular group 'n' contiguous in physical memory or not? e.g. if group 2 has suppose 5 free pages, then are all these 5 pages physically contiguous(5 * 4 * 4=80KB of contiguous block in RAM)?

Improve this question

1 Answer 1

Reset to default
1

actually contiguous physically or not?

not. that was an easy one! The mapping between physical pages and process memory is pretty much arbitrary.

whether memory allocation request will be successful in this case by using 1 page each from group 0 and group 1? or will it fail?

generally, it would work (12 kB is really very little. If your system doesn't have that many (3) contiguous pages, you have a serious problem). That's the magic of an MMU: you can reorder the physical pages in any way you want. You still would try to keep these mappings as "straight" as possible to keep the necessary tables compact, and finding of free memory fast, but it does not fail if there's not enough contiguous memory, but overall enough unused pages.

Are the pages in a particular group 'n' contiguous in physical memory or not? e.g. if group 2 has suppose 5 free pages, then are all these 5 pages physically contiguous(5 * 4 * 4=80KB of contiguous block in RAM)?

not. Especially not when you think about how your system might have another layer of nested page tables, e.g. through virtualization between physical memory and your operating system.

Improve this answer
9
  • Trying to understand better: If suppose a process requests 16 KB of free memory, and group 2 has sufficient number of free pages available, then it's guaranteed that the memory which will be allocated will be physically contiguous, right? Only when group 2 and onwards free pages are not available, only then the memory which will be allocated will be non contiguous?
    – Vishal Sharma
    Commented Sep 19, 2023 at 7:58
  • 1
    No. There's no guarantees. The Linux buddy algorithm has to take more goals into account than just delivering as little fragmented memory as possible. There's things like preferring to not have to CPU-core-coordinate page table entry modifications.
    – Marcus Müller
    Commented Sep 19, 2023 at 8:14
  • @VishalSharma I'm wondering why you're interested in userspace memory being backed by contiguous physical memory. That's because it raises all kinds of "this is a design mistake" red flags for me in the context of driver design.
    – Marcus Müller
    Commented Sep 19, 2023 at 8:16
  • 1
    Long story short: that's very very unlikely. Fragmentation doesn't lead to crashes; Linux and MMUs work pretty reliably, and a process never needs to care about the underlying physical memory; it's positively none of its concerns. Performance-wise: Yes, you get a TLB that might need to grow a lot, and then you get TLB misses, and that's bad for performance. But: couting TLB misses is pretty easy, you just ask the Linux kernel about that.
    – Marcus Müller
    Commented Sep 19, 2023 at 8:30
  • 1
    That's not a crashing process. and again, that would be trivial to find out: you'd have kernel log (dmesg) OOM entries. and, also, very unlikely scenario with packets as small as yours. This isn't complicated fragmentation, at all; also, libc will basically never return unused memory after malloc/free, so your process wouldn't even be doing any brk/mmap after a while. Note how the scenario you link to is "I need a very large piece of memory". That's not at all similar to your use case. If your process crashes, that's because your process is buggy, 99.95% of the time :)
    – Marcus Müller
    Commented Sep 19, 2023 at 10:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .