Project Home
Project Home
Documents
Documents
Wiki
Wiki
Discussion Forums
Discussions
Project Information
Project Info
Forum Topic - Physical memory defragmentation: (2 Items)
   
Physical memory defragmentation  
I've seen there has been physical memory defragmentation mentioned amongst the new features for 6.4.1. Could you tell 
more about what's that?
I suppose that should be some very-very-very low priority thread (if priorities apply to kernel code at all). Can the 
priority be made customizable?
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.