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.
A tool seen that forces programs into RAM residence
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.
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.
?? 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.
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.
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.
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.
-
technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
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.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.
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
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].