Ideal Swap Partition Size
Todd.Denniston at ssa.crane.navy.mil
Thu Jan 22 23:12:17 UTC 2009
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 :-)
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)
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)
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter
More information about the users