Ideal Swap Partition Size

[Todd Denniston]

Patrick O'Callaghan wrote, On 01/22/2009 05:20 PM:
> On Thu, 2009-01-22 at 08:57 -0600, Aaron Konstam wrote:
>> On Thu, 2009-01-22 at 12:39 +0000, Alan Cox wrote:
>>> On Wed, 21 Jan 2009 17:49:34 -0800 (PST)
>>> Leslie Satenstein <lsatenstein at yahoo.com> wrote:
>>>
>>>> Regarding swap files and intel architectures.  I believe swapping is not by pages, but by segment sizes, which is gruesome, because of performance.  
>>> Linux always pages - it doesn't use intel segmentation - in fact nobody
>>> post 286 era does.
>>>
>> Well now that I committed myself , I have question for you Alan,,
>> because I know you know the real answer.
>>
>>
>> Normally, when we talk about VM OSs we discuss a memory space and an
>> address space. VM is supposed to be mapping pages or segments from the
>> address space to the memory space and reverse. I was surprised at your
>> saying that segmentation is not being used in Linux. If it is paging
>> that is being used where is the address space that the pages reside in.
> 
> In the memory layout of a process we talk about the code, data and stack
> segments, because in the original PDP-11 architecture a segmentation
> model was easier to manage than a paging model (the machine could only
> have 8 "pages" in each segment, so there wasn't much point). This use of
> the terminology persists today. However as Alan said every modern
> machine supports paging so in practice that's what's really happening.
> It's convenient to keep the segment terminology because there are
> *logical* differences between the three segments, which the kernel uses
> in its memory management policy.
> 
> The term "swap" is also a holdback from even before the segmentation
> days, since entire processes would be moved (roll-in/roll-out). When
> Unix used a segmented model segments were moved instead of whole
> processes, but it was still called swapping, and the term "swap space"
> persists even when it's used for paging.
> 
> As if you weren't confused enough :-)
> 
> poc
> 

If Aaron is not confused enough, then may I suggest looking over at Ulrich 
Drepper's paper on LWN
What every programmer should know about memory,
Part 1 (Introduction & Commodity Hardware Today)
http://lwn.net/Articles/250967/
At the bottom of the Part 1 article there are links to the other parts.
     *  Part 2 (CPU caches)
     * Part 3 (Virtual memory) http://lwn.net/Articles/253361/
     * Part 4 (NUMA systems)
     * Part 5 (What programmers can do - cache optimization)
     * Part 6 (What programmers can do - multi-threaded optimizations)
     * Part 7 (Memory performance tools)
     * Part 8 (Future technologies)
     * Part 9 (Appendices and bibliography)


-- 
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter