[Subject Prev][Subject Next][Thread Prev][Thread Next][Subject Index][Thread Index]
Re: computing speed depends on location of swap partition??
- Subject: Re: computing speed depends on location of swap partition??
- From: "Lister Vaz" <lowenv@xxxxxxxxxx>
- Date: Wed, 7 Jul 1999 22:02:31 +0530
What is a ramdisk...and.. how does it differ from a swap partition
?????????
- ----------
> From: Lokesh_Setia <lsetia@xxxxxxxxxxxxxxxxxxx>
> To: linux-india@xxxxxxxxx
> Cc: linux-delhi@xxxxxxxxxxxxxxxxxxxxxxxxx
> Subject: Re: computing speed depends on location of swap partition??
> Date: Thursday, September 03, 1998 4:21 AM
>
>
>
> On Mon, 5 Jul 1999, Raj Mathur wrote:
>
> > Interesting. I've done some thinking about this and have come to the
> > following conclusions:
>
> I beg to differ. (somehow)
>
> >
> > 1. Most written directories:
> >
> > - swap (ok, it's not a directory!)
> > - /var
> > - /tmp
>
> For a server, yes.
> But for a PC, i think /var comes nowhere (except when booting perhaps)
> For normal surfing/emailing/programming/hacking/ I think /home is the
more
> used one than /var.
>
> Usage of swap depends on setup. For those who use brain-damaged KDE,
> nothing will help. On the other hand, console-users will find it very
hard
> to fill their RAM (even with 16 Megs). Still, i think optimizing swap is
a
> good pasttime.
>
>
> >
> > 2. Location of swap on a disk:
> >
> > In the middle. If you have multiple Linux partitions on a
> > disk, make sure that the swap partition is somewhere near the middle
> > so that seeks to the swap partition are minimised as far as possible.
>
> Yes, middle will do. In fact, if you have 2 disks, consider splitting
your
> swap partition into both your disks.
> BTW, this middle funda is no longer 100% accurate for modern disks, which
> have complex architectures.
>
> As per the partition HOWTO: usr/doc/HOWTO/mini/Partition
>
> <quote>
> . Newer disks use ZBR (zone bit recording). They have more sectors on
> the outer tracks. With a constant number of rpms, this yields a far
> greater performance on the outer tracks than on the inner ones. Put
> your swap on the fast tracks.
>
> . Of course your disk head will not move randomly. If you have swap
> space in the middle of a disk between a constantly busy home
> partition and an almost unused archive partition, you would be
> better of if your swap were in the middle of the home partition for
> even shorter head movements. You would be even better off, if you
> had your swap on another otherwise unused disk, though.
>
> Summary: Put your swap on a fast disk with many heads that is not busy
> doing other things. If you have multiple disks: Split swap and scatter
> it over all your disks or even different controllers.
>
> Even better: Buy more RAM.
>
> </quote>
>
>
>
>
> >
> > 3. Location of swap on which disk:
> >
> > On a disk different from the one containing the /var
> > directory, otherwise both will be contending for write access.
>
> Again, for a PC, I think /var is almost never used.
>
> >
> > So I put my primary swap partition in the middle of my secondary disk,
> > while my /var and /tmp are on the primary disk. Come to think of it,
> > I should move /tmp also to the 2nd disk -- should get better
> > throughput that way. Alternatively, as long as you don't use large
> > databases or ghostscript too often, and have enough RAM, make /tmp a
> > ramdisk.
>
> I won't put my /tmp on a ramdisk. I put all my files on /tmp, which i
> think i may or may not need. (On a multi-user system, you might never
know
> if some user does like this). If /tmp is on a ramdisk, its contents will
> be erased on every reboot.
> OK, solaris does like this, but people know that. Who knows probably some
> linux programs also use this fact that /tmp would not be erased on the
> next reboot. Well maybe not.
>
> For more info, see the mini-HOWTO:
> usr/doc/HOWTO/mini/Partition.
>
> Regards,
> And please correct me if i'm wrong,
>
> Lokesh Setia.
>
> > Regards, >
> > -- Raju
> >
> > >>>>> "Sundeep" == Sundeep Holani <sandi@xxxxxxxxxxxxxxxx> writes:
> >
> > Sundeep> Hi, Due to some docs that I was reading I came across an
> > Sundeep> interesting (and obvious) fact that computer speeds could
> > Sundeep> be higher if data is being accessed from multiple disks
> > Sundeep> in parallel. In this context , and in the situation that
> > Sundeep> I have 2 hard-disks , would it not boost system speeds if
> > Sundeep> the swap partition was on the disk other than the one
> > Sundeep> containing the native Linux partitions? The reason why I
> > Sundeep> think the answer should not be very obvious (to me) is
> > Sundeep> because I have in mind the way data is multiplexed with
> > Sundeep> the single system bus architecture , thus allowing only
> > Sundeep> one disk (or device for that matter) to output on the
> > Sundeep> system bus at any given time. I perhaps am not being to
> > Sundeep> explain my confusion , and thats because I am very
> > Sundeep> confused . And if the above proposal could work , does it
> > Sundeep> not make sense to place the swap partition on the
> > Sundeep> newer-faster-more_cache disk and the main partitions on
> > Sundeep> the other , or is it the other way round?? I was
> > Sundeep> wondering if somebody could work out a all-win
> > Sundeep> partitioning scheme for my following setup.. Hard-disks
> > Sundeep> -- 1) segate 2.1 gb , slow , 128 kb cache , 2) samsung
> > Sundeep> 4.3gb , faster , 300 odd kb cache . Required SW.. Linux
> > Sundeep> ofcourse... (should get main attention in performance
> > Sundeep> gain..) win-98 , win-nt-4 .
> >
> > Sundeep> Regards, Sundeep.
> >
> > --------------------------------------------------------------------
> > For more information on Linux in India visit
http://www.linux-india.org/
> >
>
>
>
>
> --------------------------------------------------------------------
> For more information on Linux in India visit http://www.linux-india.org/
- --------------------------------------------------------------------
For more information on Linux in India visit http://www.linux-india.org/
Please do not post HTML email to this mailing list. HTML mails will be
thoroughly ignored and derisively sniggered at in private.
------------------------------