Trade Off between Memory and Looping

Non release banter
Post Reply
Bogomips
Full of knowledge
Full of knowledge
Posts: 2522
Joined: 25 Jun 2014, 15:21
Distribution: 3.2.2 Cinnamon & KDE5
Location: London

Trade Off between Memory and Looping

Post#1 by Bogomips » 01 Nov 2016, 20:39

Trade Off between Running in Memory, and Looping giving rise to Extra CPU Load

Normally run Porteus Base in RAM, but recently had occasion to run the Base Modules (kernel, core, xorg, cinnamon) from a Loop. In the latter case, like to think of this as running at two remove, while in the former case the loops are running directly, at zero remove, in memory. If looping Base Modules unpacked on to a hard disk or USB, then this could be seen as running at one remove, involving i/o to hdd or USB. However the variant that was run involved looping ISO file on hard disk and then looping the Base Modules, thereby one more layer of i/o being involved, and so running at two remove. Full Description of both Setups to be found here: https://forum.porteus.org/viewtopic.php ... 986#p49986

Surprised to find hardly any difference in performance between running Porteus Base Modules in RAM, and running them from an ISO file. The only time did notice a difference was when copying a large file ~500M when the disk light unexpectedly glowed a steady red until the copy was over, which took somewhat longer longer than usual.

However numbers pan out when running an embedded Flash Video:
  • Memory Usage
    • RAM Modules

      Code: Select all

      guest@porteus:~$ free -m
                    total        used        free      shared  buff/cache   available
      Mem:            879         596          62          25         221          88
      Swap:           644         463         180
      
    • ISO Modules

      Code: Select all

      guest@porteus:~$ free -m
                    total        used        free      shared  buff/cache   available
      Mem:            879         519          94          21         265         169
      Swap:           644          39         605
      
  • CPU Load
    • RAM Modules

      Code: Select all

      Tasks: 154 total,   3 running, 151 sleeping,   0 stopped,   0 zombie
      %Cpu(s): 75.4 us, 13.0 sy,  0.0 ni, 10.6 id,  0.0 wa,  0.0 hi,  1.0 si,  0.0 st
      KiB Mem :   900936 total,    60100 free,   610448 used,   230388 buff/cache
      KiB Swap:   660152 total,   184976 free,   475176 used.    90880 avail Mem
      
      PID     USER    %CPU    %MEM    COMMAND
      1942    guest   44.4    28.4    palemoon
      7867    guest   20.9    8.6     plugin-cont+
      1422    guest   11.9    7.2     cinnamon
      1176    root    8.6     1.6     Xorg
      1322    guest   2.3     0.3     pulseaudio
      7901    guest   0.3     0.3     top
      
    • ISO Modules

      Code: Select all

      Tasks: 159 total,   2 running, 157 sleeping,   0 stopped,   0 zombie
      %Cpu(s): 84.1 us, 13.2 sy,  0.0 ni,  1.3 id,  0.0 wa,  0.0 hi,  1.3 si,  0.0 st
      KiB Mem :   900936 total,    67692 free,   600164 used,   233080 buff/cache
      KiB Swap:   660152 total,   596792 free,    63360 used.   104824 avail Mem
      
      PID     USER    %CPU    %MEM    COMMAND
      3331    guest   61.9    11.4    plugin-cont+
      1936    guest   20.2    33.6    palemoon
      1165    root    7.0     3.9     Xorg
      1410    guest   6.3     7.7     cinnamon
      1291    guest   2.3     0.6     pulseaudio
      
In both above cases video playback was enjoyable. However it is interesting to see that in the ISO case, Flash plugin container is very CPU hungry, normally around 56%, while in the case of running in RAM, it is the browser taking lion's share of CPU. Clearly running in RAM wins out here with a 10% cpu slack.

The trade off involved 260M of memory (base modules occupancy), so that when running from ISO an extra 260M/879M(total RAM) became available.
Last edited by Bogomips on 01 Nov 2016, 23:32, edited 1 time in total.
Reason: Trade Off
Linux porteus 4.4.0-porteus #3 SMP PREEMPT Sat Jan 23 07:01:55 UTC 2016 i686 AMD Sempron(tm) 140 Processor AuthenticAMD GNU/Linux
NVIDIA Corporation C61 [GeForce 6150SE nForce 430] (rev a2) MemTotal: 901760 kB MemFree: 66752 kB

jssouza
Samurai
Samurai
Posts: 172
Joined: 09 Jul 2015, 14:17
Distribution: Porteus x86 arm
Location: Liechtenstein

Re: Trade Off between Memory and Looping

Post#2 by jssouza » 01 Nov 2016, 20:57

Bogomips wrote:Surprised to find hardly any difference in performance between running Porteus Base Modules in RAM, and running them from an ISO file.
Hi Bogomips,
Is the iso mounted from a USB? (USB Flash drive/USB harddisk). USB controllers are quite fast. I too have not seen much performance difference between copy2ram and running from USB as an ISO. However, I did find a significant difference when running an iso from a slower eMMC and a slower SDcard on it (lower than a class 10). This was on a raspberry pi and I immediately found a significant performace drop when running from the eMMC as compared to running from a (faster) USB drive.

Bogomips
Full of knowledge
Full of knowledge
Posts: 2522
Joined: 25 Jun 2014, 15:21
Distribution: 3.2.2 Cinnamon & KDE5
Location: London

Re: Trade Off between Memory and Looping

Post#3 by Bogomips » 01 Nov 2016, 21:06

Hi jssouza

The ISO loaded from hard disk drive. As for USB see comment to Blaze on minichat for simple non-looping ISO. ISO from USB 2.0 > 6' 40", while same from hdd 48". Quite a difference.
Linux porteus 4.4.0-porteus #3 SMP PREEMPT Sat Jan 23 07:01:55 UTC 2016 i686 AMD Sempron(tm) 140 Processor AuthenticAMD GNU/Linux
NVIDIA Corporation C61 [GeForce 6150SE nForce 430] (rev a2) MemTotal: 901760 kB MemFree: 66752 kB

jssouza
Samurai
Samurai
Posts: 172
Joined: 09 Jul 2015, 14:17
Distribution: Porteus x86 arm
Location: Liechtenstein

Re: Trade Off between Memory and Looping

Post#4 by jssouza » 01 Nov 2016, 21:44

What I meant was, a reasonably fast storage controller, (maybe in conjunction with a fast CPU), can be good enough that it masks the performance benefits of a copy2ram.

For me, copy2ram is useful:
  • When the storage controller is slower (slower eMMC),
    When the storage controller does undue power saving (some external USB harddisks, that when once go to sleep take a long time to wake back up), running porteus from an external SD card of a phone and then the phone goes into power save and shuts down its external controllers).
    Running headless. Since the external storage is unmounted in copy2ram, a power off is a simple disconnect of the cable, without damage to the external storage.
    Boot up multiple machines with a single USB drive, kinda like a boot server - Boot one machine using copy2ram, once the boot disk is unmounted go ahead and boot the next machine and so on. Once done, all machines are ready to be used, and the USB drive goes into your pocket :)

Post Reply