Extended memory with swap in ARCH (swap to 30GB)

lilsirecho · 2006-10-19 01:35:31

One aspect of the use of the tmpfs (as opposed to the custom /mytmpfs) is that swap on becomes a part of the system and a "reset" may be needed to eliminate the swap added. Because this is a "live" boot, no problem should be encountered with that procedure.

The same does not occur while using a custom /mytmpfs which deletes all of the added swap data and leaves a 400-500MB swap to deactivate in about a minute's time. Again, a reset could be used at that juncture.

lilsirecho · 2006-10-19 18:56:55

A comparison test was conducted using the same data transfers with separate swap drives...internal versus external 2.0USB. 20GB in each drive. Indicated speeds are during swap activity only as indicated by ksysguard and external activity led on USB drive.

External USB transferred from hda3 at ~14MB/S ....

Internal hdb2 drive accepted transfers at ~27MB/S....

Test with both swaps enabled with 30G limit in /mytmpfs showed a nominal rate of 26MB/S for all transfers up to 29GB at which time a warning of critical loading to /mytmpfs directory and a slow down in transfer speed. This indicates that speed is not compromised after the 20GB size of the internal drive is exceeded until the load limit is reached.
Swap drive sharing is evidently working.

No further tests planned....................

lilsirecho · 2006-10-21 00:18:57

Pergormed tests with /devhdc,/devhdd, and sda used in priority swap while in arch, loading same with data from hda3.

Loaded my mp3 file of 3.6GB at rates averaging 36MB/S with high of 42 and low of 32.

Loaded 5.9GB .iso file at an average of 40GB/S with low of 33 and a high of 44.

Loaded 1GB .vob files at an average of 37MB/S, high 41 and low of 30.

Loaded 1GB .avi file at an average of 34MB/S, low of 28 and high of 37.

Loaded packages .tar.gz with many stalled sections with a high of 41MB/S and a low of 28 with most of the transfer in the mid thirty range.

The sda2 swap showed activity at all times during ~20GB of transfers.

====================================================================================

Tests with /dev/hdc2 and /devsda2 produced ~25MB/S average with mp3 file of 3.6GB

Loading .iso file of 5.9GB produced an average of 33MB/sec

Loading of .vob files produced an average of 33MB/S

Loading of packages .tar.gz of 5.9GB produced an average of 24MB/S

Sda2 was active throughout.
==============================================================================

This indicates swap is more efficient with the secondary HDD's used for swap, each having 7200rpm drives in my system.

I cannot run larch with secondary HDD's installed but perhaps can use hdb for the DVDrom and test the system while booted to copy-to-ram in larch.

lilsirecho · 2006-10-21 02:00:57

EDIT:Booted into larch copy to ram with DVD D/L disc .......Performed transfers again but with DVDrom installed at hdb and using three HDD's in secondary IDE and USB 2.0 as before.

The transfers for all files as before itemized was very steady and averaged 33MB/S. Packages .tar.gz again evidenced some stalling in the indicator of transfer speed but was still averaging 33MB/S. No stalls occured during other transfers of video and .iso.

A total of 19GB was transferred with sda2 indicating activity during swap transfers.
==============================================

Transfers with hdc DVD D/L packages .tar.gz as the source produced 7 to 13MB/S transfer speed with a nominal 10MB/S during swap transfers.

Transfers before swap onset were also at 10MB/S.

The hda3 drive is DMA 6 in normal install without the DVDrom and hdparm states dma is on for that drive. I would not expect hda3 to be dma 6 in this config. There is an 80 wire cable installed and cable select has been jumpered.

Upon reboot, will check the status of Hda3 in bios.

Best results so far..................

lilsirecho · 2006-10-21 02:09:36

Rebooted...listed values for dma on all drives in bios:

Pri IDE HDA DMA 6

HDB DMA 2

Sec IDE HDC dma 6

HDD dma 6

Loading for the hard drive transfers were made from hda3.

lilsirecho · 2006-10-23 04:37:08

Tested swap use while using DVD in HDD slot to load to larch copy-to-ram with the 20GB swap in HDC slot, maxtor dma 6.

Verified via hdparm -i /dev/hdc was operated dma6 during the test.

The transfer rate after swap was initiated (3GB ram) at 1GB of data transferred was between 25MB/S and 35MB/S for all data types loaded as specified in earlier posts.

Then, the WD400 USB drive was installed with priority 3 swap of 20GB and additional data entered via hda3. The speed remained above 25MB/S with this added swap device which extends the size to 40GB.

Then, the hda3 arch HDD, also a maxtor, was disconnected from the primary bus and installed in the USB/IDE enclosure. The test setup was cleared, re-initiated with a fresh swap designation for hdc2, and transfers made from the USB HDD.

The speeds obtained were very stable for all data files at just under 17MB/S indicating limiting by the USB/IDE hardware interface.

Some tests were performed changing the transfer sector size with the command:

echo (size*) >/sys/block/sda/device/max_sectors

The largest size I tried was 1028...default is 240. None of the selections made any impact on performance with USB swap as extended ram I did not try the same procedure with internal HDD swap sector size.

The use of the DVD on the same cable in secondary IDE may have some effect. The primary IDE can be empty during the running of Larch since it isn.t used(except in my tests it provides the data files).

When operating with USB HDD for data source, 17MB/S is very steady.

If data were transferred fromthe DVDrom, 10MB/S would be expected.

I conclude that internal swap can be used to extend ram by large amounts and good transfer speeds are evident. The addition of USB external swap HDD extends the size of extended ram further with a minor ~5MB/S impact on transfer speed. Operation of archlinux with these system changes is enhanced by extended ram and is not slowed when using copy-to-ram mode.

I have not tried a normal boot of larch with extended ram introduced...maybe next...

lilsirecho · 2006-10-23 16:30:37

Loading larch without copy to ram permitted transfers from the USB/IDE interface at 16+MB/S to /mytmpfs for all files and folders utilized for these tests. Again, the speed indication was very steady..flat. The hdc2 swap partition was used.

Hdd_cd was opened and openoffice-base installed via ...pacman -Ud which took 25 seconds. Mplayer loaded in four seconds, mozilla-firefox 17 seconds and seamonkey 5 seconds.

There is a delay before the KDE menu shows these items.

lilsirecho · 2006-10-24 15:38:05

Present layout has hdc slot with maxtor DMA6 7200rpm and hdd slot has Sony DVD d/l @ dma2. Larch loads from the DVD.

Swap size in maxtor is ~20GB and it loads almost all data files at a nominal 25 MB/S while operating in this config. DMA verified with hdparm -i ...... Data source is hda3 for the tests and the machine has 3GB ram.

Perhaps I should call this arrangement ...."ramshackled"...?

The first data files installed enter ram in copy-to-ram Larch at ~40MB/S until ram is full and kswapd maintains the system ram required. After loading many GB of data into swap, the resulting situation seems to place all the new data into swap but has a residual ~0.5G of system files left in swap. When unmounting the /mytmpfs file, the residual data remains in swap, the bulk of the data is deleted instantly. Swapoff -a command serves to remove the residual and does so by transferring it back to ram system files via the swap mechanism in arch. This takes about a minute for that sized residual.

All packages loaded via pacman in Larch are installed r/w such that even those originally installed r/o can be changed to r/w via pacman upgrade.

Auf deutch, Ich haben ein," grossenundbiggenundfattenundhugeprimaoperat".

lilsirecho · 2006-10-24 16:35:05

One final note:

Loaded the packages folder of 5.4GB from DVD while in copy-to-ram larch in ~10 minutes at a nominal 10MB/S. Swap file was in hdc2, DVD in hdd. 4.7GB loaded to swap.

The transferred packages folder opens instantly in arch /mytmpfs, no delay noted.

Noted that cpu was maxed in ksysguard.

Writing this from Larch copy-to-ram.

lilsirecho · 2006-11-09 18:39:58

Just finished installing Larch2 on a DVD+RW disc.

It produced a faster boot since it did not include the packages(3200) which the dual-layer version included. The boot time was 1 minute 45 seconds. This boot time was for copy-to-ram and it showed ~770MB of ram in use. The DVD has ~550MB included, small enough for a CD burn.

Utilizing the dual-layer packages in the DVD rom I was able to install open office in 17 seconds, mplayer in four seconds, opera in four seconds and codeine in less than 2 seconds.

As before, my system has 3GB of ram. I loaded 5.9 GB of .iso from the DVDrom at 16+MB/sec into /mytmpfs, utilizing 20GB swap in hdc2 partition, the DVDrom is installed as Hdd. No problems were encountered with the operation of the arch system using this procedure.

Arch is up and running in copy-to-ram as I prepare this post.

Installation of Larch2, after a failed attempt I must admit, was smooth and uneventful, probably a half hour to execute, including the burn to DVD at 4X. Many thanks to gradgrind for his great effort!!

Operation without copy-to-ram is provided but is slower in execution. In ram mode, the system seems as fast as a normal arch boot.

I have found no limit to swap use in this configuration.

brazzmonkey · 2006-11-09 20:04:59

don't you feel alone in here ?

PipoDeClown · 2006-11-10 20:57:08

interesting read.

since i decide it was stupid to sacrifice a partition for swap i dont use swappartition anymore.

instead i create a swapfile in my root fs.

512MB:
  dd if=/dev/zero of=/swapfile bs=1024 count=524288

commit to disk:
  flush

no need for users to access it: 
  chmod 600 /swapfile

format the swapfile:
  mkswap /swapfile

enable swap
  swapon /swapfile

edit /etc/fstab to mount it automatically:
  /swapfile  swap  swap  defaults  0 0

lilsirecho · 2006-11-10 21:49:46

PipoDe Clown: I appreciate your approach to eliminating a swap partition and dedicating a file for the purpose. That is an option with the caveat of file size limits.

My whole approach has been directed toward using swap to increase the RAM. In oder to do this, a tmpfs mechanism was utilized. This application permits using swap aftere ram is exhausted. In fact, it permits the entire contents of any hard drive to extend RAM.

As far as I know, tmpfs is the only mechanism which automatically extends RAM with swap.

Thus, it isn't just a swap interface in the usual sense, often limited to a small partition as you remarked.

I spent much time investigating the consequences of various swap drive assignments, including trials of the parallel use of swap drives. I attempted to portray the use of extended RAM in this manner including pro and con.

If one has a 1GB RAM machine, a live CD of Larch can be extended in RAM to very large size with full drive swap assigned. My DVD experiments demonstrated 3200 packages were loadable in dual-layer disc and provide for R/W install of any program with dependencies.

This allows testing of any and all desired programs without having deleterious effects on the operating system(since it is a live boot-up and can be restored by reboot).

So, the purpose of my swap is a special application of extended RAM, perhaps to allow many DVD videos to be stored. This is possible due to the ejection of the boot CD/DVD in copy-to-ram permitting the use of the rom for additional installs.

In addition, pacman can be invoked to install packages via unionfs which are installed R/W. Thus, even those programs originally installed as R/O can be re-installed by pacman to be R/W.

If the user has a CD/DVD with tar.gz packages, they too can be installed with pacman via the command: pacman -Ud (path to targz).

Not the same as normal swap but used for macro purposes to extend RAM and need not be internal to the machine, nor limited by file size limits.

Thanks for your descriptive post regarding swap files versus swap partitions. It does free up a partition for other assign.

iphitus · 2006-11-11 08:37:47

lilsirecho wrote:

PipoDe Clown: I appreciate your approach to eliminating a swap partition and dedicating a file for the purpose. That is an option with the caveat of file size limits.
My whole approach has been directed toward using swap to increase the RAM. In oder to do this, a tmpfs mechanism was utilized. This application permits using swap aftere ram is exhausted. In fact, it permits the entire contents of any hard drive to extend RAM.
As far as I know, tmpfs is the only mechanism which automatically extends RAM with swap.

swap can't be used "as ram"

when something get's swapped out, to be used, it has to be swapped back into ram -- it can't be used directly from the hdd, it has to be in ram. so you cannot use a hard drive as ram.

swap exists to theoretically extend the storage, but for anything in that swap to be processed it has to be swapped back into ram again, causing hard drive access, which in turn causes system slowdowns -- a hard disk isnt a substitute for ram, in any form. Only a last resort to push inactive things out to.

James

lilsirecho · 2006-11-11 16:33:10

Iphitus: As a last resort, not "as ram", but as extended ram, most definitely not ram speed, but controlled transfer through kswapd in paged format.

If one has 1GB ram and desires to load 8GB of material into"ram", the only mechanism is swap via tmpfs and it seems it has no limits.

As pointed out by Pipo deClown, swap partitions could be replaced by swap files, freeing up a partition for other purposes. I tested full hdd swap partitions as an experiment.

Swap via tmpfs can be external to the machine via usb as I pointed out.

I do not expect blinding speed from swap used in this manner, certainly won't permit 3D games!!

When utilizing copy-to-ram with a live CD/DVD, much of ram is used in loading the disc into ram. Thus, to enjoy the benefits of faster execution while in ram and still load large files, the swap mechanism is available. The same is available when not running the CD/DVD in ram, but the speed of operations is greatly reduced.

Also, when operating in ram, external swap hdd in use, permits operating with less heat in the machine since all internal devices can be shut down.

A further advantage is testing of new programs without jeopardizing the installed system since the system can be restored with a reboot.

I surmise the pagefile system, when used with a fully swap partitioned hdd, may be more efficient than when applied to a multi-partitioned hdd.

My experiments have permitted normal arch system operations while utilizing copy-to-ram with ram size greatly exceeded, kswapd in full operation. I experienced no slowdowns up to this point in my trials, certainly not "hundreds of times slower".

I performed the same tmpfs mechanism in normal arch boot exceeding ram size by large amounts and found no slowdown evident. Probably 3D gaming wouldn't get off the ground!

Still, just an experiment... the new larch2 "mini" sized install might permit less than 1GB of ram be sufficient to copy-to-ram and then load much more with tmpfs and swap and see what can be done with minimal ram..perhaps slower?

Theoretically, parallel swap devices are possible. Such mechanisms would improve swap speed. Some references suggest multi-partitioned swap drives each partition with the same priority. In a single drive thusly partitioned, anywhere is in a valid partition on the drive, faster execution therefore seems possible.

More to do in experimenting.........

lilsirecho · 2006-11-15 14:10:20

A quote from googling:

Using swap space for temporary storage

Under some UNIX variants, notably Solaris and Linux, you can use the tmpfs filesystem; this uses VM as storage space. When you have ample RAM, this provides an excellent way of supporting very fast disk access; unused files will be swapped on to disk. The result is a highly efficient solution for fast access to the files you use most often, and it can be a significant speed boost for applications, such as software development, where a large number of temporary files are created during the compilation process.

This remark applies to tmpfs in the event ram is not overrun....in the Larch system I use, two tmpfs entries were made, the tmpfs provided by Larch and mytmpfs wherein the data was entered. The Larch generated tmpfs entry is undisturbed by the activities I performed.

I note this item for completeness but it applies to usual swap activities rather than extended ram applications.

lilsirecho · 2006-11-17 19:50:36

A further note in using tmpfs in Larch c2r. This activity utilizes the system without installing large files into swap /mytmpfs, but uses tmpfs as provided by the Larch install.

Mounted sda1HDD. Moved 900+MB file to desktop (tmpfs ) at ~20MB/sec.

Moved the same file back into sda1HDD @ 106MB/sec. That is a USB/IDE interface device, mounted.

This activity indicates that mounted device transfer rates permit file read/writes at high speed(near the 133 bus speed in my computer).

This might also apply to swap USB HDD's mounted as /mytmpfs as has been shown in previous postings. Granted, the pagefile system is purportedly in command of swapped data.

I find that the transfer rate into HDD while transferring as /mytmpfs swap is nearly the same as normal transfers into HDD.

When performed in normal arch boot, the /mytmpfs swap of , say 20GB, is deleted from the HDD almost in its entirety in one unmount action. There is usually about 500MB of swap left to remove.

This seems to indicate that the excess data beyond 500MB is essentially handled as a single entity, one giant repository.

Do I interpret this action incorrectly?

lilsirecho · 2006-11-18 05:15:22

Some further notes with the new Larch 2.0 as the vehicle.

Booted to c2r (copy-to-ram) and established a mounted /mytmpfs directory.

Loaded mytmpfs with 8.4GB of video and mp3 data, and some DIB.avi...

Most of the files loaded from HDA3 at 25MB/sec and the DIB files at 20MB/S from sda1.

A 20GB swap file was generated in HDC2 hdd.

The final vmstat appears below:

[root@n6re ~]# vmstat
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 9106876 332060 7624 2056372 2245 5366 6608 6429 679 1314 10 16 40 34
[root@n6re ~]#

While the data was available in /mytmpfs, I moved each file singly to desktop. The transfer rate varied with the type of file material, the best transfer was an avi video at an average of 22MB/Sec. Others started at that figure but fell to 5,6,8 and 10MB/s in mid-transfer but recovered to 18 to 20MB/sec. All files were 1GB to 2GB in size.

Each file was played in VLC to verify quality good.

Then each file was moved back into /mytmpfs. Transfer speed for most of the files was in excess of 160MB/sec. Some of the material was transferred at 25 to 50 MB/sec.

I then unmounted /mytmpfs. Immediately, the memory in use fell to 177344KB used.
I find this to indicate a special category for the data added in /mytmpfs after the Least Recently Used (LRU) files have been swapped(592+MB as shown below). An exact picture of the status is problematic, since the data being added is least recently used of a different type!!!!.

I then noted swap in use at 592608KB used.

I then ran swapoff...it took 53 seconds to clear the swap partition.

The memory in use then climbed to 752400KB in use. The CD has 588MB burned.

I just completed these tests and am writing this in Larch2 boot-up.

Those who understand the mechanism may decide to explain same.

I found the speed of the USB device to be more stable than previous runs with the original larch1.09.

My Larch 2.0 CD uses the stock arch kernel.

Arch Linux

#51 2006-10-19 01:35:31

Re: Extended memory with swap in ARCH (swap to 30GB)

#52 2006-10-19 18:56:55

Re: Extended memory with swap in ARCH (swap to 30GB)

#53 2006-10-21 00:18:57

Re: Extended memory with swap in ARCH (swap to 30GB)

#54 2006-10-21 02:00:57

Re: Extended memory with swap in ARCH (swap to 30GB)

#55 2006-10-21 02:09:36

Re: Extended memory with swap in ARCH (swap to 30GB)

#56 2006-10-23 04:37:08

Re: Extended memory with swap in ARCH (swap to 30GB)

#57 2006-10-23 16:30:37

Re: Extended memory with swap in ARCH (swap to 30GB)

#58 2006-10-24 15:38:05

Re: Extended memory with swap in ARCH (swap to 30GB)

#59 2006-10-24 16:35:05

Re: Extended memory with swap in ARCH (swap to 30GB)

#60 2006-11-09 18:39:58

Re: Extended memory with swap in ARCH (swap to 30GB)

#61 2006-11-09 20:04:59

Re: Extended memory with swap in ARCH (swap to 30GB)

#62 2006-11-10 20:57:08

Re: Extended memory with swap in ARCH (swap to 30GB)

#63 2006-11-10 21:49:46

Re: Extended memory with swap in ARCH (swap to 30GB)

#64 2006-11-11 08:37:47

Re: Extended memory with swap in ARCH (swap to 30GB)

#65 2006-11-11 16:33:10

Re: Extended memory with swap in ARCH (swap to 30GB)

#66 2006-11-15 14:10:20

Re: Extended memory with swap in ARCH (swap to 30GB)

#67 2006-11-17 19:50:36

Re: Extended memory with swap in ARCH (swap to 30GB)

#68 2006-11-18 05:15:22

Re: Extended memory with swap in ARCH (swap to 30GB)

Board footer