Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
HOWTO: Mount / in RAM and load apps instantly
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3, 4, 5, 6  Next  
Reply to topic    Gentoo Forums Forum Index Documentation, Tips & Tricks
View previous topic :: View next topic  
Author Message
Stephonovich
n00b
n00b


Joined: 20 May 2004
Posts: 72
Location: United States

PostPosted: Sun Jul 31, 2005 1:50 am    Post subject: Reply with quote

Sheepdogj15 wrote:
has anyone heard about the Gigabyte i-RAM? i'm wondering if it will be supported by existing linux drivers (i don't see why not... just uses a SATA hdd interface), but if so, it could very well make these issues irrelevant. that is, assuming you have the money for it and 4 sticks of RAM, of course. ;)


Yeah, I was thinking about that awhile ago. Supposedly they'll get support for 4GB by the time they launch. I'd mount /usr (as much as possible, anyway) and /var in there. Ah... visions of nearly instantaneous emerge --sync...
_________________
Who needs reincarnation when you've got parallel universes?
Back to top
View user's profile Send private message
Sheepdogj15
Guru
Guru


Joined: 07 Jan 2005
Posts: 430
Location: Backyard

PostPosted: Sun Jul 31, 2005 2:14 am    Post subject: Reply with quote

yeah, definitely. though i'm not so concerned about portage, as that's something i can run in the background while i'm doing other things. otherwise yeah... it will be very nice to get away from head latency and finally make full use of that 150MB/s pipe. :)
_________________
Sheepdog
Why Risk It? | Samba Howto
Back to top
View user's profile Send private message
Beige Tangerine
n00b
n00b


Joined: 13 Jun 2004
Posts: 7

PostPosted: Tue Aug 02, 2005 5:39 pm    Post subject: unionfs / ldd script Reply with quote

Based on some comments here, I've been working on some init scripts to mount only certain libraries in memory. I'm using a bash script (formerly a Perl script, but I wanted it to be able to run at boot time, even if /usr wasn't mounted) that runs ldd on any given files, follows symlinks, and automatically copies the appropriate libraries to ramdisks (one ramdisk for /usr/lib and one for /usr/bin). Then I use unionfs to mount each ramdisk together with its original directory.

I'm actually not terribly impressed with the load-time decrease on the one computer I've tried, but I think it's just because the hard drive is fast. (I can cat about 50MB worth of libraries to /dev/null in about a second and a half, if memory serves.) However, those of you who see 7-second improvements from your first boot of Firefox to the next are probably still very interested.

Then again, you might not even need to mount the libraries on a RAM disk. It might just be enough to read the libraries from disk (cat /usr/lib/whatever > /dev/null) so that they're stored in the cache. This may have much the same effect as starting Firefox (or whatever) once and then closing it. It would also avoid the dilemma of how to handle writes to /usr/lib (like when you update your system); my plan was to offer two runlevels: one that used ramdisks and had /usr/lib mounted read-only, and one that did not use ramdisks and had /usr/lib mounted read-write. If the performance gains are roughly equal, it would be much simpler not to have to worry about this.

Anyway, I'll post the script once I get home. It's not quite finished, especially since I'm not sure it's worth it for the computer I tried it on, but the part that lists all libraries required by the given programs seems to be working fairly well.
Back to top
View user's profile Send private message
Beige Tangerine
n00b
n00b


Joined: 13 Jun 2004
Posts: 7

PostPosted: Wed Aug 03, 2005 12:56 pm    Post subject: Re: unionfs / ldd script Reply with quote

Here's the script. It has some comments, and I'll put some more below.

/etc/init.d/ramlibs
Code:
#!/sbin/runscript

# TODO checkconfig section
# TODO die if a dir doesn't exist
# TODO note file that configuration comes from

function listLibs()
{
  declare -a ALL_LIBS

# In theory, readlink might not be available because /usr/bin might not be mounted.
# My understanding is that we can assume that /bin is mounted (likewise for /lib, since it has libraries the bash requires).
# Actually, this happens after localmount, so I don't think that's a concern.
# Still, I found that busybox readlink is faster than standard readlink, so I'm not going to mess with it for now.

# We need busybox for this, but it appears to be pulled in by 'emerge system," so we should be able to count on it.
# Interestingly, this even beats the normal readlink -f for speed.
  function readlink()
  {
    busybox readlink -f $1
  }

# Normal readlink version.
#function readlink()
#{
#  `which readlink` -f $1
#}

  function appendToAllLibs()
  {
    ALL_LIBS[${#ALL_LIBS[*]}]=$1
    echo $1
  }

  function isInAllLibs()
  {
    for (( J = 0 ; J < ${#ALL_LIBS[*]} ; J++ )); do
      if [[ ${ALL_LIBS[$J]} == $1 ]]; then
        true; return
      fi
    done

    false; return
  }

  while [[ $# -ne 0 ]]; do
    appendToAllLibs `readlink $1`
    shift
  done

# Looking at the output, I get the impression that recursion is not actually be necessary.
# I'm not sure, but the script is slower if we leave it in.
# Use the commented-out for() instead of the ORIG_COUNT and other for() to "reactivate" it.
#for (( I = 0 ; I < ${#ALL_LIBS[*]} ; I++ )); do
  ORIG_COUNT=${#ALL_LIBS[*]}
  for (( I = 0 ; I < $ORIG_COUNT ; I++ )); do
    CURRENT_LIB=${ALL_LIBS[$I]}

# The commented-out version spawns a subshell, which means that ALL_LIBS is local to it.  Not good.
#  ldd 2> /dev/null $CURRENT_LIB | sed -e 's/^\t//' | sed -e 's/^.* => //' | sed -e 's/ (0x.*)$//' | grep -v '^$' | grep -v '^statically linked$' | while read LIB; do

    for LIB in `ldd 2> /dev/null $CURRENT_LIB | sed -e 's/^\t//' | sed -e 's/^.* => //' | sed -e 's/ (0x.*)$//' | grep -v '^$' | grep -v '^statically linked$'`; do
      LIB=`readlink $LIB`
      if ! isInAllLibs $LIB; then
        appendToAllLibs $LIB
      fi
    done
  done
}

function start()
{
  LIBS=(/usr/lib/MozillaFirefox/firefox-bin /usr/lib/MozillaThunderbird/thunderbird-bin /usr/bin/AbiWord-2.2 /usr/bin/gnumeric /usr/bin/gimp-2.2 /usr/bin/leafpad /usr/bin/xpdf /usr/bin/rhythmbox /usr/bin/gmplayer /usr/bin/oggenc /usr/bin/cdparanoia /usr/bin/eject /usr/bin/easytag)
  ebegin "Copying libraries from ${#LIBS[@]} programs to RAM"

# TODO remove to config file
  MERGEDIRS=(/usr/bin /usr/lib64)
  RAMDIRS=(/usr/bin_ram /usr/lib64_ram)
  HDDIRS=(/usr/bin_hd /usr/lib64_hd)

  for (( I = 0 ; I < ${#MERGEDIRS[@]} ; I++ )); do
    MERGEDIR=${MERGEDIRS[$I]}
    RAMDIR=${RAMDIRS[$I]}
    HDDIR=${HDDIRS[$I]}

    mount tmpfs $RAMDIR -t tmpfs

    mount -t unionfs -o dirs="$RAMDIR=ro:$HDDIR=ro" none $MERGEDIR
  done

  if [[ ${#MERGEDIRS[@]} -ne ${#RAMDIRS[@]} || ${#MERGEDIRS[@]} -ne ${#HDDIRS[@]} || ${#RAMDIRS[@]} -ne ${#HDDIRS[@]} ]]; then
# TODO say what file to edit
    eerror "Arrays MERGEDIRS, RAMDIRS, and HDDIRS must be of equal length."
  fi

  einfo "Test variable: $TESTING"

# TODO Note that spaces will probably break this.
  listLibs ${LIBS[@]} | while read LIB; do
    for (( I = 0 ; I < ${#MERGEDIRS[@]} ; I++ )); do
      MERGEDIR=${MERGEDIRS[$I]}
      RAMDIR=${RAMDIRS[$I]}
      HDDIR=${HDDIRS[$I]}


      if echo $LIB | grep "^$MERGEDIR" > /dev/null; then
        LIBDIR=`dirname $LIB`
        SHORTLIBDIR=`echo $LIBDIR | sed -e "s#^$MERGEDIR##"`
        mkdir -p $RAMDIR$SHORTLIBDIR

        SHORTLIB=`echo $LIB | sed -e "s#^$MERGEDIR##"`
        cp $HDDIR$SHORTLIB $RAMDIR$SHORTLIBDIR
      fi
    done
  done
}

function depend()
{
  before *
  need localmount
}

function stop()
{
# TODO remove
  MERGEDIRS=(/usr/bin /usr/lib64)
  RAMDIRS=(/usr/bin_ram /usr/lib64_ram)
  HDDIRS=(/usr/bin_hd /usr/lib64_hd)

  estart "Unmounting library RAM drives"
  for (( I = 0 ; I < ${#MERGEDIRS[@]} ; I++ )); do
    MERGEDIR=${MERGEDIRS[$I]}
    RAMDIR=${RAMDIRS[$I]}
    HDDIR=${HDDIRS[$I]}

    umount $MERGEDIR
    umount $RAMDIR
  done
}


In theory, LIBS, MERGEDIRS, RAMDIRS, and HDDIRS would eventually be moved to /etc/conf.d/ramlibs.

You need busybox installed. I think it's part of system now, so you should probably have it. If not, emerge it.
You also need unionfs, which you can get from portage.

There's a circular dependencies complaint at shutdown.

Here's the most important function:
listLibs file1 [file2 [file3 ...]]
Print a list of libraries (with duplicates removed and symlinks fully resolved) required by the given file(s). (This includes the file itself. Note that this won't work for scripts, e.g., rip. That's why my LIBS contains '/usr/bin/oggenc /usr/bin/cdparanoia /usr/bin/eject')

Note that the current version of the script is for AMD64 (hence lib64 instead of lib).

As currently written, the script expects the "real" /usr/lib64 to be mounted at /usr/lib64_hd. (You would probably have to move the directories at the console and edit /etc/fstab.) It also expects /usr/lib64 and /usr/lib64_ram directories to exist (and, presumably, to be empty). (/usr/bin is similar, with /usr/bin_hd and /usr/bin_ram.) The script scans the files in LIBS, and any files it lists from /usr/lib64 and /usr/bin are copied from the appropriate _hd directory to the appropriate _ram directory. Then each _ram/_hd pair of directories is mounted together with unionfs, e.g., /usr/lib64 is /usr/lib64_ram and /usr/lib64_hd. This way, the system looks on the ramdrive first for any libraries.

Currently /usr/bin and /usr/lib64 are mounted read-only. Mounting the RAM drive read/write is a bad move because any changes you make to it (probably with portage) will be wiped on reboot. (It might also fill up quickly if you emerged something large, like Eclipse.) You could write a script to copy /usr/lib64_ram to /usr/lib64_hd at shutdown time, but if the power goes out or the computer locks up, you might have problems. Mounting the hard drive read/write is also bad, because any changes made by portage, etc. to a library that is also present on the RAM drive will not show up until you reboot, which is odd behavior.

My plan had been to eventually create another init script that just mounted a read/write copy of /usr/lib64_hd at /usr/lib64 (and similarly, /usr/bin_hd at /usr/bin). I would put it in a new runlevel, and then I could choose at bootup whether I wanted the fast, unmodifiable libs or the slower, writeable libs. In theory, you could even switch runlevels once you had started, though it would involve closing down X and other programs, since they would be using the libraries.

Oh, and a warning: Don't try this with /bin or /lib. The system needs to be able to run bash at startup. Bash is located in /bin, and it requires libraries in /lib. I'd go so far as to say that there is almost certainly a way to get around this, but I didn't think it would be worth it, as most of the files in those directories are small, anyway. Your situation may vary.

Let me know if you have any questions. I'm sure I missed some important things. Finally, let me reiterate that this is NOT a finished script. If you want to use it, you'll have to play around with it, and it's easy to make your system unbootable along the way.
Back to top
View user's profile Send private message
apberzerk
Apprentice
Apprentice


Joined: 11 Jan 2004
Posts: 278
Location: kansas...

PostPosted: Thu Aug 04, 2005 5:39 am    Post subject: Reply with quote

I've seen several posts concerning this issue: what happens when you emerge something and write to the ramdisk? I am uncomfortable with the idea of just updating the HD with the contents of the ramdisk on shutdown. If the system fails and for some reason does not shut down properly, you lose the results of your emerges.

It seems to me that the following would be really nice to have (and I don't know how much of it already exists):

When something writes to /usr/lib or /lib or whatever you have mounted in ramdisk, it writes to the hard drive as well as the ramdisk. When something reads from any of these locations, it reads from ramdisk. How would such a thing be implemented?
Back to top
View user's profile Send private message
Beige Tangerine
n00b
n00b


Joined: 13 Jun 2004
Posts: 7

PostPosted: Thu Aug 04, 2005 2:34 pm    Post subject: Reply with quote

apberzerk wrote:
I've seen several posts concerning this issue: what happens when you emerge something and write to the ramdisk? I am uncomfortable with the idea of just updating the HD with the contents of the ramdisk on shutdown. If the system fails and for some reason does not shut down properly, you lose the results of your emerges.

It seems to me that the following would be really nice to have (and I don't know how much of it already exists):

When something writes to /usr/lib or /lib or whatever you have mounted in ramdisk, it writes to the hard drive as well as the ramdisk. When something reads from any of these locations, it reads from ramdisk. How would such a thing be implemented?
As I understand it, this isn't possible with unionfs, though I may be overlooking something. See "Writing to Union" at the unionfs website:
Quote:
...all changes are stored in leftmost branch.
In other words, just the ramdisk, or just the hard drive, but not both.

This is why I had planned to mount the ramdisk/hard drive union read-only and offer a separate, hard-drive-only mode for running portage, etc. (Well, I was also worried that the ramdisk would fill up if I emerged something like Eclipse:)
Code:
cpovirk@eleventy ~ $ du -sk /usr/lib/eclipse-3/
102115  /usr/lib/eclipse-3/
Anyone have any other ideas?
Back to top
View user's profile Send private message
Sheepdogj15
Guru
Guru


Joined: 07 Jan 2005
Posts: 430
Location: Backyard

PostPosted: Fri Aug 05, 2005 1:30 am    Post subject: Reply with quote

i haven't messed with Ramdisk, but i have a few things set up in a tmpfs "partition." what i do is have it untar my stuff into the tmpfs on startup and set my mount points. on shutdown, it retars all the contents (in case something has changed, like i did an emerge). i've also made a backup tarball after a major emerge in case my computer dies before it can have a successful shutdown. i figure as long as i remember to do the backups or at least never have nasty system crashes, i'll be fine. :?
_________________
Sheepdog
Why Risk It? | Samba Howto
Back to top
View user's profile Send private message
apberzerk
Apprentice
Apprentice


Joined: 11 Jan 2004
Posts: 278
Location: kansas...

PostPosted: Fri Aug 05, 2005 6:30 pm    Post subject: Reply with quote

Sheepdogj15 wrote:
i figure as long as i remember to do the backups or at least never have nasty system crashes, i'll be fine. :?


I have one of those every week I think...

- Phil
Back to top
View user's profile Send private message
SaBer
n00b
n00b


Joined: 11 Aug 2005
Posts: 16

PostPosted: Fri Aug 12, 2005 8:05 am    Post subject: Reply with quote

apberzerk wrote:
I've seen several posts concerning this issue: what happens when you emerge something and write to the ramdisk? I am uncomfortable with the idea of just updating the HD with the contents of the ramdisk on shutdown. If the system fails and for some reason does not shut down properly, you lose the results of your emerges.

It seems to me that the following would be really nice to have (and I don't know how much of it already exists):

When something writes to /usr/lib or /lib or whatever you have mounted in ramdisk, it writes to the hard drive as well as the ramdisk. When something reads from any of these locations, it reads from ramdisk. How would such a thing be implemented?


Could one perhaps create a raid1-array with a partition and a ramdisk?
_________________
There are 10 kinds of people in this world: Those who understand binary, and those who don't.
Back to top
View user's profile Send private message
R4miu5
Apprentice
Apprentice


Joined: 01 Feb 2005
Posts: 263
Location: Mödling / Austria

PostPosted: Thu Aug 18, 2005 2:22 pm    Post subject: Reply with quote

as far as i know the section

Code:
echo /sbin/update-balls >> /etc/conf.d/local.stop
chmod +x /sbin/update-balls
cat /sbin/update-balls


will run the creation of the tarballs at every shutdown?
Back to top
View user's profile Send private message
blue666man
n00b
n00b


Joined: 01 Mar 2005
Posts: 15

PostPosted: Fri Aug 19, 2005 10:18 am    Post subject: Reply with quote

I think some readers on this forum might find this interesting:

It's a 66MHz 64-bit PCI-X (NOT pci express) card. Features:

Capacity: 2GB, 4GB, 8GB, 16GB
Battery backup: Multiple Redundant, Rechargeable On-board Batteries
Semaphore DMA Initiator for maximizing read and write transfers
Supports Interrupts
Error Detection and Correction
Burst Mode Transfer Rate: 533 MB/s peak

Some ppl were looking into the Gigabyte ramdisk, but I don't see the real benefit since I/O on SATA-I is capped at 150MB/s. The other, bigger, problem with solid state disks which use IDE or SATA is that you're not getting the 'R' benefit of RAM. All OS's handle IDE, SCSI, and SATA with sectors on a disk in mind. Not to mention, all your fav. file systems: reiser, xfs, jfs, ext*, etc. are also built around the fact that fragmentation slows access because a DISK has to spin and a r/w head has to move. There's no such thing on CMOS'es. But gigabyte and company will never make a ramdisk that ISN'T IDE or SATA b/c M$ Winblows can't handle what linux can: ramfs. :evil:

Anyway, if someone has a xeon MB with a PCI-X slot, I'd take a look into this card. Imagine a 16GB big filesystem where every I/O's seektime is in the hundreds of nanoseconds, not singles of milliseconds (about 20 to 25 times faster)! And a throughput of 533 MB/s! Not to mention the joy of seeing your PC boot as quickly as a palm pilot, but I digress.
Back to top
View user's profile Send private message
Jonasx
Tux's lil' helper
Tux's lil' helper


Joined: 26 Mar 2004
Posts: 118

PostPosted: Wed Sep 14, 2005 7:21 pm    Post subject: Reply with quote

If your having trouble getting the linuxrc to execute, try taking the first row of hashes out, seems I needed the interpreter as the first line to make it go through...

also, you may need to specify the fs type with the -t option in linuxrc file when you mount. This is the only way I could get a reiser4 part to mount here.

I've almost gotten a native 64bit system w/ 2 gigs of ram like I want it, I'll post some of my experiences and hang ups shorty so it may help some others out :)

Edit:

And thaks for the great how to :)
_________________
"If you understand what you're doing, you're not learning anything." - Anon
Back to top
View user's profile Send private message
gingekerr
n00b
n00b


Joined: 12 Aug 2005
Posts: 4
Location: Reigate/Cambridge, UK

PostPosted: Mon Sep 19, 2005 1:59 pm    Post subject: Reply with quote

Is it not possible just to take advantage of the linux disk caching by doing a cat /lib/* > /dev/null ? (or something slightly smarter with find or for... test -f &&
This has no fixed memory usage, no problems with improper shutdowns and is all-in-all simpler. Of course, it doesn't have the security advantages of RAM root partitions.
Back to top
View user's profile Send private message
Enlight
Advocate
Advocate


Joined: 28 Oct 2004
Posts: 3519
Location: Alsace (France)

PostPosted: Tue Sep 20, 2005 3:36 pm    Post subject: Reply with quote

gingekerr wrote:
Is it not possible just to take advantage of the linux disk caching by doing a cat /lib/* > /dev/null ? (or something slightly smarter with find or for... test -f &&
This has no fixed memory usage, no problems with improper shutdowns and is all-in-all simpler. Of course, it doesn't have the security advantages of RAM root partitions.


readahead <file> if I remember correctly.
Back to top
View user's profile Send private message
frawd
n00b
n00b


Joined: 21 Sep 2005
Posts: 5

PostPosted: Sun Oct 02, 2005 9:03 pm    Post subject: Reply with quote

Anyone think that using this and prelinking binaries could give any kind of problems?

http://www.gentoo.org/doc/en/prelink-howto.xml

Would it speed up loading times more or is it just not worth it?

Thanx
Back to top
View user's profile Send private message
Enlight
Advocate
Advocate


Joined: 28 Oct 2004
Posts: 3519
Location: Alsace (France)

PostPosted: Mon Oct 03, 2005 2:45 pm    Post subject: Reply with quote

frawd wrote:
Anyone think that using this and prelinking binaries could give any kind of problems?

http://www.gentoo.org/doc/en/prelink-howto.xml

Would it speed up loading times more or is it just not worth it?

Thanx


If your tarballs are correctly updated, I can't see how this could cause troubles. And I would say that yes It can speed a bit things but you won't fell it as much as when your libs and progs are on the disk. (adn I personnaly saw very few difference whan it is on HD)
Back to top
View user's profile Send private message
adsmith
Veteran
Veteran


Joined: 26 Sep 2004
Posts: 1386
Location: NC, USA

PostPosted: Mon Oct 03, 2005 3:11 pm    Post subject: Reply with quote

gingekerr wrote:
Is it not possible just to take advantage of the linux disk caching by doing a cat /lib/* > /dev/null ? (or something slightly smarter with find or for... test -f &&
This has no fixed memory usage, no problems with improper shutdowns and is all-in-all simpler. Of course, it doesn't have the security advantages of RAM root partitions.


This sounds like a much better idea.

In particular, how about this:
Code:

abe@tock ~ $ eix readahead
* sys-apps/readahead-list
     Available versions:  ~0.20050320.2320 ~0.20050323.0658 ~0.20050328.0142 ~0.20050425.1452 0.20050517.0220
     Installed:           none
     Homepage:            http://tirpitz.iat.sfu.ca/
     Description:         Perform readahead(2) to pre-cache files.


Haven't tried it yet, but it seems liks this sort of option is much better. Let the kernel itself deal with moving things from page cache -- it's very good at it, afterall. All you need to do is let it know what you want pre-lopaded. This seems safer and less hackish than an involved tar/mount script. It's also probably faster, though I have no proof yet.
Back to top
View user's profile Send private message
adsmith
Veteran
Veteran


Joined: 26 Sep 2004
Posts: 1386
Location: NC, USA

PostPosted: Mon Oct 03, 2005 3:32 pm    Post subject: Reply with quote

more info on preloading:
https://bugs.gentoo.org/show_bug.cgi?id=64724
This is ueber-simple to set up, and appears to work very well.
Back to top
View user's profile Send private message
Frunktz
n00b
n00b


Joined: 25 Oct 2005
Posts: 2

PostPosted: Tue Oct 25, 2005 2:11 pm    Post subject: Reply with quote

Well, in this way I lost some minute for extract tarball and copy the context on the RAM. Am I wrong?
Thanks a lot.
Ps:- Copy the /usr in RAM took me about 15-20 sec...
Back to top
View user's profile Send private message
Adwin
Tux's lil' helper
Tux's lil' helper


Joined: 13 Mar 2005
Posts: 128
Location: Poland

PostPosted: Sun Oct 30, 2005 1:37 am    Post subject: Reply with quote

The most important thing is commiting changes both on the ramdisk files AND syncing them in real time to HDD files.
Any idea how to do this, except for rsync ?
Back to top
View user's profile Send private message
SaBer
n00b
n00b


Joined: 11 Aug 2005
Posts: 16

PostPosted: Tue Nov 01, 2005 9:57 am    Post subject: Reply with quote

Adwin wrote:
The most important thing is commiting changes both on the ramdisk files AND syncing them in real time to HDD files.
Any idea how to do this, except for rsync ?


I'm still thinking raid1...

Check this out: http://lkml.org/lkml/2005/9/4/223
_________________
There are 10 kinds of people in this world: Those who understand binary, and those who don't.
Back to top
View user's profile Send private message
TenPin
Guru
Guru


Joined: 26 Aug 2002
Posts: 500
Location: Kansas City

PostPosted: Sat Nov 05, 2005 9:19 pm    Post subject: Reply with quote

So this essnetially moves the hard disk load times from when you run an application to boot time and ensures that stuff is permanently cached. It also adds time cosuming retarballing for when you emerge something into the tmpfs or shut down.

Another way of doing this could be to just cat /usr/bin/blah > /dev/null all the libraries and binarys that you want to be cached on boot. Then they will be cached and if you have lots of ram will stay cached.

I find that with 512Mb that the kernel caching works just fine and loading openoffice or firefox for the second time is instantaneous. Sure I lose the cache if I need to use that memory but thats better than having the memory locked into a tmpfs and having to use swap.

It seems to be more trouble than its worth to do this, especially on a laptop which is being shutdown frequently.
_________________
For since in the wisdom of God the world by its wisdom did not know God, God was pleased to save those who believe by the foolishness of preaching.
Back to top
View user's profile Send private message
brazzmonkey
Guru
Guru


Joined: 16 Jan 2005
Posts: 372
Location: between keyboard and chair

PostPosted: Wed Feb 15, 2006 8:49 am    Post subject: Reply with quote

adsmith wrote:
how about this:
Code:

abe@tock ~ $ eix readahead
* sys-apps/readahead-list
     Available versions:  ~0.20050320.2320 ~0.20050323.0658 ~0.20050328.0142 ~0.20050425.1452 0.20050517.0220
     Installed:           none
     Homepage:            http://tirpitz.iat.sfu.ca/
     Description:         Perform readahead(2) to pre-cache files.


Haven't tried it yet, but it seems liks this sort of option is much better. Let the kernel itself deal with moving things from page cache -- it's very good at it, afterall. All you need to do is let it know what you want pre-lopaded. This seems safer and less hackish than an involved tar/mount script. It's also probably faster, though I have no proof yet.


how do you get it configured ? i couldn't find relevant documentation on this one.
Back to top
View user's profile Send private message
adsmith
Veteran
Veteran


Joined: 26 Sep 2004
Posts: 1386
Location: NC, USA

PostPosted: Wed Feb 15, 2006 1:24 pm    Post subject: Reply with quote

You edit /etc/conf.d/preload, something like this:
Code:

## verbosity.  0-9, Default is 4.
PRELOAD_VERBOSITY="3"

## this is where preload will store its pid file
#PRELOAD_PIDFILE="/var/run/preload.pid"
## can't get this to work.. :(

## set this for niceness. Default is 15
PRELOAD_NICE="15"

## log file
PRELOAD_LOGFILE="/tmp/log/preload.log"


Then you need an init file, something like this:
Code:

#!/sbin/runscript
# Copyright 1999-2005 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

opts="${opts} reload dump"


#depend() {
#       after xdm
#}

dump() {
    ebegin "Dumping config and state for preload"
    killall -SIGUSR1 /usr/sbin/preload
    killall -SIGUSR2 /usr/sbin/preload
    eend $?
}


reload() {
    ebegin "Reloading config for preload"
    killall -SIGHUP /usr/sbin/preload
    eend $?
}
 
start() {
        ebegin "Starting preload"
        start-stop-daemon --start --quiet --exec /usr/sbin/preload -- \
    --logfile ${PRELOAD_LOGFILE} -V ${PRELOAD_VERBOSITY} -n ${PRELOAD_NICE}
        eend $?
}

stop() {
        ebegin "Stopping preload"
        start-stop-daemon --stop --quiet --exec /usr/sbin/preload
        eend $?
}
Back to top
View user's profile Send private message
brazzmonkey
Guru
Guru


Joined: 16 Jan 2005
Posts: 372
Location: between keyboard and chair

PostPosted: Wed Feb 15, 2006 1:37 pm    Post subject: Reply with quote

ok, thanks for that.
i suppose i also have to edit a list so that it knows what has to be preloaded. am i right ? if so, where's this list ?
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Documentation, Tips & Tricks All times are GMT
Goto page Previous  1, 2, 3, 4, 5, 6  Next
Page 4 of 6

 
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