[lkml]   [2004]   [Feb]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Active Memory Defragmentation: Our implementation & problems

--- "Richard B. Johnson" <>
> All "blocks" are the same size, i.e., PAGE_SIZE.
> When RAM
> is tight the content of a page is written to the
> swap-file
> according to a least-recently-used protocol. This
> frees
> a page. Pages are allocated to a process only one
> page at
> a time. This prevents some hog from grabbing all the
> memory
> in the machine. Memory allocation and physical page
> allocation
> are two different things, I can malloc() a gigabyte
> of RAM on
> a machine. It only gets allocated when an attempt is
> made
> to access a page.

Only userspace processes are allocated pages via
page-faults, i.e., one page at a time. Processes
running in kernel mode can request higher order blocks
(8K,16K...4M, which are 2 pages,4 pages...1024 pages
respectively) from the buddy allocator directly. If
external fragmentation is rampant, requests for these
higher order blocks may fail. The defragmentation
utility intends to provide a faster option for higher
order block formation before swapping (which is the
last alternative). By the way,
malloc finally takes memory from the buddy allocator
itself (by page-faults), & the defragmenter is out to
reduce the external fragmentation caused by the buddy
allocator. Swapping ofcourse cannot be completely
avoided if the machine is genuinely short of memory.
Defragmentation may now sound better than needless
swapping or memory allocation failures, not just
another cpu hog!


Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:00    [W:0.113 / U:5.628 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site