How do I install vmtouch on Slackware?
mgutt opened this issue · 8 comments
Sadly I'm not able to find a tgz package and I don't know how to build one.
Ok, I'm not sure if this is the correct way, but I did the following:
cd /tmp
# deb2tgz
wget https://packages.slackonly.com/pub/packages/14.2-x86_64/misc/deb2tgz/deb2tgz-0.2-noarch-1_slonly.txz
upgradepkg --install-new deb2tgz-0.2-noarch-1_slonly.txz
# ar (needed by deb2tgz)
wget http://slackware.cs.utah.edu/pub/slackware/slackware64-14.2/slackware64/d/binutils-2.26-x86_64-3.txz
upgradepkg --install-new binutils-2.26-x86_64-3.txz
# download vmtouch deb package
wget http://archive.ubuntu.com/ubuntu/pool/universe/v/vmtouch/vmtouch_1.3.1-1_amd64.deb
# deb to tgz conversion
deb2tgz "vmtouch_1.3.1-1_amd64.deb"
# install vmtouch
upgradepkg --install-new vmtouch_1.3.1-1_amd64.txz
Sources:
https://slackware.pkgs.org/14.2/slackonly-x86_64/deb2tgz-0.2-noarch-1_slonly.txz.html
https://slackware.pkgs.org/14.2/slackware-x86_64/binutils-2.26-x86_64-3.txz.html
https://ubuntu.pkgs.org/20.04/ubuntu-universe-amd64/vmtouch_1.3.1-1_amd64.deb.html
Hmm. Seems not to work (RAM usage was extremely high, too)
vmtouch -v -d -l "/mnt/user/movies/file.mkv"
vmtouch -v -t -p -60M "/mnt/user/movies/file.mkv"
/mnt/user/movies/file.mkv
[OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO] 15360/15360
Files: 1
Directories: 0
Touched Pages: 15360 (60M)
Elapsed: 0.019109 seconds
vmtouch "/mnt/user/movies/file.mkv"
Files: 1
Directories: 0
Resident Pages: 0/6207469 0/23G 0%
Elapsed: 2.5259 seconds
I'm not sure exactly the process on slackware, but if it's running and you're seeing output I guess it installed correctly.
Can you please expand on why you don't believe it's working? The first command looks like you are trying to lock a 23G file in memory? And you are then checking if the first 60M are resident (which it seems they are?).
why you don't believe it's working
I don't know why, but now it works. I'm not sure how, but I think I triggered a race condition somehow while testing different variantes of the command while the daemon was still crawling the file. Sadly I'm not able to reproduce it. The final result was as you see it above. Although I executed different commands, the last command returned "Resident Pages: 0/6207469 0/23G 0%" which should be "100%" or at least return the "60M" of the second command.
EDIT: Hmm.. this is strange, too:
vmtouch "/mnt/disk1/Movie/OP"
Files: 213
Directories: 137
Resident Pages: 13053541/850054462 49G/3242G 1.54%
Elapsed: 13.49 seconds
As you can see 49G is in the page cache.
Now I lock it:
vmtouch -v -d -l -m 60M "/mnt/disk1/Movie/OP"
But of 62GiB are still 60GiB available:
free -h
total used free shared buff/cache available
Mem: 62Gi 927Mi 623Mi 818Mi 61Gi 60Gi
Swap: 127Gi 22Mi 127Gi
Isn't it possible to lock files that are already present in the RAM? Let's test it by emptying the cache:
sync; echo 1 > /proc/sys/vm/drop_caches
Status after cache cleaning:
vmtouch "/mnt/disk1/Movie/OP"
Files: 213
Directories: 137
Resident Pages: 386/850054462 1M/3242G 4.54e-05%
Elapsed: 12.575 seconds
Repeat crawl:
vmtouch -v -d -l -m 60M "/mnt/disk1/Movie/OP"
Check after some minutes:
vmtouch "/mnt/disk1/Movie/OP"
Files: 213
Directories: 137
Resident Pages: 386/850054462 1M/3242G 4.54e-05%
Elapsed: 12.488 seconds
Ok, now I'm confused ^^ Let's try with -p
:
vmtouch -v -d -l -p 0M-60M "/mnt/disk1/Movie/OP"
vmtouch "/mnt/disk1/Movie/OP"
Files: 213
Directories: 137
Resident Pages: 2247618/850054462 8G/3242G 0.264%
Elapsed: 12.957 seconds
Ok, this command works and the crawled file parts were locked as well:
ps aux | awk '{print $6/1024 " MB\t\t" $11}' | sort -n | grep vmtouch
2.63672 MB vmtouch
2.83594 MB vmtouch
8761.03 MB vmtouch
And I think I found another problem. This command crawls the complete file:
vmtouch -v -d -l "/mnt/user/movies/file.mkv"
Shoudn't it crawl only "500M" as mentioned in the manual?
-m <max file size>
Maximum file size to map into virtual memory. Files that are larger than this will be skipped. Examples: 4096, 4k, 100M, 1.5G. The default is 500M.
Shoudn't it crawl only "500M" as mentioned in the manual?
No, -m
is supposed to entirely skip files larger than this amount (by default).
I suggest not using the daemon mode during testing, it's easy to forget you have one running.
skip files larger than this amount
Ok, makes sense. I mean the manual says "skip". I don't know why I thought about partial crawling. Sorry for that ^^
deleted
No worries. -m
was sort of hack in the first place. People would accidentally crawl a directory with a gigantic file in it and it would grind their system to a halt. The 500M
was totally arbitrary. Maybe this flag is unnecessary now.