Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Tue 16 Sep 2014, 17:35
All times are UTC - 4
 Forum index » Advanced Topics » Cutting edge
A tool seen that forces programs into RAM residence
Moderators: Flash, Ian, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 1 of 1 [6 Posts]  
Author Message
gcmartin

Joined: 14 Oct 2005
Posts: 4274
Location: Earth

PostPosted: Thu 05 Sep 2013, 10:52    Post subject:  A tool seen that forces programs into RAM residence  

Improving response-time in desktop operations
I saw this article and thought it would be prudent to ask the community for comment of whether this has applicability in Puppyland. Puppy is already a very fast distro running RAM-centric.

Here's one thought:
Puppy, when booting pfix=ram, set up its filesystem in RAM. but, it appears to carry out its operations via the I/O subsystem for its application-data operations. This mimics a real HDD's operation.

If the tool suggested by this URL is employed in a PUP, would that mean that certain PUP tools would not deploy thru the filesystem accesses, but rather, would bypass filesystem to use a 'direct' RAM execute path.

I may not be looking at this accurately.

Question
What I am wondering is if the I/O subsystem was bypassed for some apps, would this provide benefit? And, if so, are there any drawbacks?

Any ideas would be helpful in understanding.

_________________
Get ACTIVE Create Circles; Do those good things which benefit people's needs!
We are all related ... Its time to show that we know this!
3 Different Puppy Search Engine or use DogPile
Back to top
View user's profile Send private message 
Ted Dog


Joined: 13 Sep 2005
Posts: 2326
Location: Heart of Texas

PostPosted: Thu 05 Sep 2013, 11:40    Post subject:  

Next version of Fatdog64 will have a boot option expand2ram=yes that will uncompress the entire image in RAM (balloons to take about 800M) but it will blow the dust out of the decompression carburetor and allows the hardware to turbo charge scream!
Its hard to quantify instant program starting numerically so It feels like the machine is about 10X faster. There is a lot of flashing stuff and lists appear so briefly that normal splash screens just blimps on/off so fast as to think there is a video glitch somewhere. Wink
Back to top
View user's profile Send private message 
Karl Godt


Joined: 20 Jun 2010
Posts: 3972
Location: Kiel,Germany

PostPosted: Thu 05 Sep 2013, 12:09    Post subject:  

Quote:
but, it appears to carry out its operations via the I/O subsystem for its application-data operations. This mimics a real HDD's operation.

PROVE THIS !
Back to top
View user's profile Send private message Visit poster's website 
Ted Dog


Joined: 13 Sep 2005
Posts: 2326
Location: Heart of Texas

PostPosted: Thu 05 Sep 2013, 18:04    Post subject:  

?? prove a RAM drive ??

To me it sound like someone's something to make the idea of a RAM drive layer like we use in almost all puppylinux spins into something 'new' and special.
We can do the same by touching the file and thereby sifting them into the RAM layer as a change, next time called it would be in the 'fast' RAM section.
Back to top
View user's profile Send private message 
amigo

Joined: 02 Apr 2007
Posts: 2247

PostPosted: Sat 07 Sep 2013, 12:23    Post subject:  

The way puppy normally works live, any running program is in RAM twice. Once (compressed) inside the intrd which is mounted like a filesystem. When the program gets executed, the ld-linux loader loads it into RAM (uncompressed) and links any needed libs to it in the correct places.

Traffic between the mounted initrd (or any other FS image) does go through the normal I/O routines -a loop mount means it is being treated as a 'device' which contains a file system. But, since the access to this virtual device takes place in RAM, there is hardly any latency when reading or writing data -no disk spinup times, etc. However, the data does still traverse the same internal I/O routines -unless DMA is available and enabled. Last I looked DMA was still not possible in the loop module.

In the article, preload is mentioned, but it does nothing except pre-load libraries according to a list. The claimed faster times for program loading are iffy. The speedup is the same as one would notice when running a program the second time -since it has already been loaded and linked before, it is (most likely) still in the cache and so, must not be reloaded. preload may even slow down *boot times*.

Puppy already takes advantage of the speedups possible from using a RAM drive, tmpfs, loop-mount mechanism. The only other possibility which *might* be faster would be to use an XIP-capable file system -that's Execute In Place. Or, by using suspend techniques so that the system never really goes down.
Back to top
View user's profile Send private message 
technosaurus


Joined: 18 May 2008
Posts: 4351

PostPosted: Wed 11 Sep 2013, 16:43    Post subject:  

amigo wrote:
The way puppy normally works live, any running program is in RAM twice. Once (compressed) inside the intrd which is mounted like a filesystem. When the program gets executed, the ld-linux loader loads it into RAM (uncompressed) and links any needed libs to it in the correct places.
Tinycore had a patch to use tmpfs vs ramfs for initrd, but recently Rob Landley posted a less hacky version to the LKML. With tmpfs you get a swap backed cache and the benefits of XIP, plus you can perform remounts on / ... no more need for switch_root as long as the unioning fs can cope.


Of course the best option is to include the initramfs in the kernel and compress the kernel, but not the initramfs (it still gets compressed because it is included and double compressing is rarely useful)... and now we can use lz4 compression, which is slightly better than lzo at decent compression rates with fast decompression (Its a toss-up whether it is faster than uncompressed images depending on disk read vs. cpu speed)

Although that means everything in the initramfs takes up RAM, but you can use zswap to offset it in case free ram gets too low without any significant performance hit

_________________
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 1 of 1 [6 Posts]  
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Advanced Topics » Cutting edge
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.0600s ][ Queries: 12 (0.0040s) ][ GZIP on ]