Page MenuHomeFreeBSD

Coalesce physical memory segments
ClosedPublic

Authored by alc on Aug 31 2018, 6:00 PM.
Tags
None
Referenced Files
Unknown Object (File)
Jan 11 2024, 11:49 PM
Unknown Object (File)
Sep 21 2023, 5:35 PM
Unknown Object (File)
Sep 11 2023, 4:51 AM
Unknown Object (File)
Sep 1 2023, 9:36 PM
Unknown Object (File)
Sep 1 2023, 9:34 PM
Unknown Object (File)
Sep 1 2023, 9:34 PM
Unknown Object (File)
Sep 1 2023, 9:08 PM
Unknown Object (File)
Aug 21 2023, 3:06 PM
Subscribers

Details

Summary

Recent changes have created, for the first time, physical memory segments that can be coalesced. Since we sometimes iterate over the physical memory segments, coalescing these segments at initialization time is a worthwhile change.

In principle, coalescing at the time of segment definition, in vm_phys_add_seg(), would be the ideal approach. However, in practice, coalescing can't occur until later, after free queues have been assigned to each segment.
Moreover, the code to perform coalescing in a single pass over the physical memory segments is much simpler than examining and potentially merging each new segment with its predecessor and successor.

What follows is an example from a machine artificially configured to have 1.5GB of RAM, although the limited RAM is not really a cause for the existence of coalescable segments.

Before

vm.phys_segs: 
SEGMENT 0:

start:     0x10000
end:       0x9a000
domain:    0
free list: 0xffffffff8204feb0

SEGMENT 1:

start:     0x103000
end:       0x200000
domain:    0
free list: 0xffffffff8204feb0

SEGMENT 2:

start:     0x200000
end:       0x1000000
domain:    0
free list: 0xffffffff8204feb0

SEGMENT 3:

start:     0x1000000
end:       0x270d000
domain:    0
free list: 0xffffffff8204fc40

SEGMENT 4:

start:     0x2717000
end:       0x274c000
domain:    0
free list: 0xffffffff8204fc40

SEGMENT 5:

start:     0x2800000
end:       0x5d748000
domain:    0
free list: 0xffffffff8204fc40

After

vm.phys_segs: 
SEGMENT 0:

start:     0x10000
end:       0x9a000
domain:    0
free list: 0xffffffff8204feb0

SEGMENT 1:

start:     0x103000
end:       0x1000000
domain:    0
free list: 0xffffffff8204feb0

SEGMENT 2:

start:     0x1000000
end:       0x270d000
domain:    0
free list: 0xffffffff8204fc40

SEGMENT 3:

start:     0x2717000
end:       0x274c000
domain:    0
free list: 0xffffffff8204fc40

SEGMENT 4:

start:     0x2800000
end:       0x5d748000
domain:    0
free list: 0xffffffff8204fc40

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

Why not coalesce phys_avail[] ranges instead ? I believe that we handle such range if it should be split between proximity domains, looking at the code in vm_phys_create_seg().

In D16976#362278, @kib wrote:

Why not coalesce phys_avail[] ranges instead ? I believe that we handle such range if it should be split between proximity domains, looking at the code in vm_phys_create_seg().

Fragmentation of phys_avail[] is not the cause. This fragmentation of vm_phys_segs[] arises from the "special" calls to vm_phys_add_seg(), those that don't derive directly from phys_avail[], like we do for the initial kernel page table pages and now for the kernel and modules loaded at boot time.

This revision is now accepted and ready to land.Sep 1 2018, 5:49 PM
This revision was automatically updated to reflect the committed changes.