[Sussex] Microsoft Windows minimum system's

Tue Aug 8 13:25:29 UTC 2006

DCB

On Tue, 2006-08-08 at 11:21 +0000, d binderman wrote:
> >Many moons ago when I did the Solaris System Internals course I recall
> 
> Is Linux the same or diffierent implementation to Solaris ?

Different.  IIRC, Solaris works out the swap page it will use when the
RAM page is allocated, Linux clusters dirty RAM pages and writes them as
a block to swap.

> As a side issue, I'd be mildly interested to find out how XP does it.

So am I, but I'm not planing on going on a XP/Vista internals course any
time.

> >(hopefully correctly) that when a application request another page of
> >RAM the kernel not only allocates it a chuck of memory, but also
> >allocates the page in the swap where that page of memory will be written
> >to if needed.  It is built into Solaris that all pages (except for a few
> >used by the kernel) are always backed up by a page somewhere on disk.
> 
> Interesting way to do it. Can't say I've heard of anyone else doing it
> that way, but it's a while since I looked into this.

I remember saying that when Sun switched from BSD to SVR4 part of the
switch over included Sun donating their memory management code to the
SVR4 source.  They hard worked hard on it and it must have been the very
good as SVR4 was the base for a lot of Unixs.  So anyone else that use
the same code pase that Solaris does/did should also do it the same way.

> Does it imply the kernel keeping track of swap pages that it doesn't
> know if it is going to use or not in some possible future use ?

Not sure what your asking here.  A kernel (any kernel) must keep track
of free swap pages.  The kernel must also track the location of every
page.  When it is in RAM which physical page the virtual page maps to,
and when on disk which disk page it maps to (swap or normal file
system).  The difference is going to be how each kernel manages both
lists.

> >Of course if you want an application to have the best possable disk
> >performance then dedicate the whole disk (or more than one disk) to that
> >application and don't put a swap parition on it.
> 
> Good tip, and I've always found putting more RAM in a box to be the
> #1 hot tip for speeding it up, on the basis that RAM is faster than disk.
>
> I can agree with you that high performance top end machines [ SGI etc]
> do run no-swap and indeed, gigabytes of high performance SRAM cache memory
> used as main memory too.
> 
> Hence the expense.

Any system configuration is going to be a compomise.  If you have a
machine that only does one task then it is possible to tune it to be
faster at that.  I think it is FreeBSD that came up with a file system
tuned to containing lots and lots of small files becuase news server
performance as killed by FFS way of handling small files.  But for most
the FFS was the beter FS.

To me the swapless general purpose Linux system[1] is one compomise to
far.  If you are running without swap then you must have enough RAM for
your peek load.  For most systems the peeks are a lot higher than the
level need to cope with 80% or even 90% for peek load.  For less money
you could just added a disk that is only used for swap - and that way it
will have no impact on the I/O of the other file systems.

I must admit I have changed the way I lay out my partitions on disk
these days.  I use to do it the old way it was done by Sun.  The first
partition was /, the second was swap, with /usr and /home following on
behind.  The swap partition (which these days is really small compared
to the overall disk size) was bunched up close to the edge of the disk.

When I sat down and thought about the problem it became clear that the
thing I wantted to do was minimise head movements.  So now I place a
really, really small /boot partition at the start, then I place swap in
the middle of the disk and then allocate my partitions moving out from
the middle.  The idea is that the partitions containing data used most
offen are closest to the moddle of the disk[1] and therefore, over time,
I've minimised head movement.

Steve

[1] By middle I don't mean the centre point around which the disks spin.
This is an edge.  The middle is half way between center and the outter
edge.  This isn't has hard as it sounds.  When using cfdisk(8) or
fdisk(8) which the units to cylinder mode.  For example my disk on this
machine is layed out thus:

 Disk Drive: /dev/sda
 Size: 203928109056 bytes, 203.9 GB
 Heads: 255   Sectors per Track: 63   Cylinders: 24792

 Device     B Start End   Size Mount
 ----------------------------------------------------------------
 /dev/sda1  * 1     92    118M /boot
 /dev/sda5    93    2092   16G /
 /dev/sda6    2093  10092  62G /home
 /dev/sda7    10093 12092  16G /usr
 /dev/sda8    12093 12792      Swap
 /dev/sda9    12793 14792  16G /var
 /dev/sda10   14793 16792  16G 
 /dev/sda11   16793 18792  16G /usr/local
 /dev/sda12   18793 20792  16G
 /dev/sda13   20793 22792  16G
 /dev/sda14   22793 24792  16G /usr/src

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://mailman.lug.org.uk/pipermail/sussex/attachments/20060808/8cfd5591/attachment.pgp 