Douglas Bailey
|
RE: Physical memory defragmentation
|
Douglas Bailey
04/20/2009 8:59 AM
post27465
|
RE: Physical memory defragmentation
Yes, we have started introduction of physical memory defragmentation
with the 6.4.1 release. You can find most of the source in
services/system/memmgr/memmgr_defrag.c and
services/system/memmgr/mm_defrag.c. The design documentation is at:
http://community.qnx.com/sf/wiki/do/viewPage/projects.core_os/wiki/Physi
calMemoryFragmentation
In 6.4.1 we introduce a "minimal compaction" algorithm, and lay the
groundwork for future efforts. The minimal compaction algorithm does
not run in the background, so priority as such is not an issue. Rather,
if a memory request is made for contiguous memory, and that request
cannot be satisfied with available free memory, the minimal compaction
algorithm runs while the thread that requested the memory is blocked.
The compaction algorithm runs with the priority of the requesting
thread.
All the minimal compaction algorithm does is scan memory and look for a
chunk that could be swept free. It then runs through that chunk, moving
any allocated pages to new locations. There are many reasons that we
can't move a page, so finding a movable run of sufficient size is not
necessarily straight forward. The algorithm attempts to avoid any
disruption of other threads that are running on the system. It
obviously does impact the thread that was allocating memory when the
compaction algorithm was triggered, but only in the event that the
memory allocation otherwise would fail.
And, of course, it can be disabled through a procnto command-line
switch.
We've talked about a number of possible additional mechanisms for the
future, such as pro-actively defragmenting free memory, defragmenting
inuse memory (fragmentation of inuse areas is not as big an issue for
memory as it is for disk, as there is no benefit to read speed with
defragmented memory. There is, however, a benefit if we can use a large
page TLB to map an area of memory), sweeping application allocations out
of the area preferred by the kernel, etc. However, none of these
activites are scheduled for 6.4.2 -- we're going to wait and get a bit
of experience with what we have before we proceed.
|
|
|