vmtouch failing to mlockall >1g suddenly (maybe update?)

[agowa]

Hi,

after rebooting a server vmtouch (v1.3.1) now suddenly (probably forgot to reboot after updating) fails to lock more than 1G. Even with ulimits increased an arbitrary high -m parameters to it.

It stops at exactly 500259 pages (1G) each time. I have (currently) still 4G memory completely free and ulimits (after poking it) are:

# ulimit -a
real-time non-blocking time  (microseconds, -R) unlimited
core file size              (blocks, -c) 0
data seg size               (kbytes, -d) unlimited
scheduling priority                 (-e) 0
file size                   (blocks, -f) unlimited
pending signals                     (-i) 23578
max locked memory           (kbytes, -l) 10485760
max memory size             (kbytes, -m) unlimited
open files                          (-n) 999999
pipe size                (512 bytes, -p) 8
POSIX message queues         (bytes, -q) 819200
real-time priority                  (-r) 0
stack size                  (kbytes, -s) 8388608
cpu time                   (seconds, -t) unlimited
max user processes                  (-u) 23578
virtual memory              (kbytes, -v) unlimited
file locks                          (-x) unlimited

# cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux trixie/sid"
NAME="Debian GNU/Linux"
VERSION_CODENAME=trixie
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

Example commands I used to poke at this issue (all ran as root):

• vmtouch -L -p 0-50k -f /opt/mycachefiles/ => vmtouch: WARNING: unable to mmap file X (Cannot allocate memory), skipping and LOCKED 500259 pages (1G)
• vmtouch -m 1000000000 -L -p 0-50k -f /opt/mycachefiles/ => vmtouch: WARNING: unable to mmap file X (Cannot allocate memory), skipping and LOCKED 500259 pages (1G)
• vmtouch -m 128 -L -p 0-50k -f /opt/mycachefiles/ => vmtouch: WARNING: file X too large, skipping and LOCKED 98 pages (392K)

What limit is this hitting? Maybe a regression of #35 sounds most likely atm. Am I missing something?

Edit: after further testing:
vmtouch -L -p 0-100k -f /opt/mycachefiles/ => vmtouch: WARNING: unable to mmap file X (Cannot allocate memory), skipping and LOCKED 669225 pages (2G)
So is this some kind of file descriptor limit (other than ulimit -n?)

Edit 2: Probably not. The issue appears to be specific to the combination of -l/L and -p:

• vmtouch -L -f /opt/mycachefiles/ => vmtouch: WARNING: unable to mmap file X (Cannot allocate memory), skipping and LOCKED 1170529 pages (4G), this one at least could also have been an out of memory issue from running vmtouch over and over again. The system only has 6G total. However it still doesn't explain why using -p in addition would cause it to fail so much sooner...
• vmtouch -f /opt/mycachefiles/ => "Just works", therefore it's not an issue with the amount of file descriptors. However it sparks more questions than it answers... Total stats btw:

           Files: 92867
     Directories: 873
  Resident Pages: 1232468/1854039  4G/7G  66.5%
         Elapsed: 3.0882 seconds