vmtouch load file into memory even without any arguments.

[slashbeast]

Hi.

Looks like vmtouch always load into memory whatever it tests. I did some tests on few big files, running 'vmtouch /path/to/foo.mkv' took about 4s and after that printed that the file is 100% in memory, it wasnt. After droping cache via /proc/sys/vm/drop_caches again the vmtouch took 4s and according to free the file was just prefetched into memory. I did the test on two boxes, one running ext4, dmcrypt and lvm (many layers) and another running just reiserfs.

[hoytech]

I have not observed this behaviour before. With no arguments, vmtouch is only supposed to open() the file, mmap() it, and then call mincore() on the memory. It is possible that the OS is prefetching the file which would be undesirable from the vmtouch perspective.

I'll try to look into this further. Thanks for the report.

[hoytech]

Please re-open this if more information comes up and/or a reproducible test case is built. Thanks.

[slashbeast]

Well I can reproduce it on every Gentoo's deployment I have, with or without lvm and dmcrypt, 32bit and 64bit. Also on 64bit Debian, when I test <50 kB files it does not 'load them' when testing 200kB and bigger files it always is touched into memory

./vmtouch /var/cache/apt/archives/*

Files: 496
Directories: 1
Resident Pages: 111282/111286 434M/434M 100%
Elapsed: 6.3232 seconds

I am not sure hwo can I reopen this bug tho...

[hoytech]

OK I will try to look into why this is. Maybe there's an mmap flag or something we can use to prevent the OS from pre-fetching if that is in fact what's happening.

Thanks for the follow-up. Reopening the issue.

[slashbeast]

Friendly bump

[hoytech]

Sorry nothing yet, but I am on-and-off working on a "libvmtouch" that will have a much better test suite and should help diagnose this issue.

[slashbeast]

Hey,

Seems like the issue is no more. I've tested older commits and still, it does work like it should so it had to be something about all the systems I've tried it on.

fwiw its no longer an issue with kernel 4.1.0-rc5, glibc 2-21 and gcc 4.9.2.

[hoytech]

Thanks for letting me know. Cheers.