[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Ideal Swap Partition Size



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 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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]