You can't swapoff because the amount of swapped memory can't be overtaken by your RAM. You are getting legitimate error message.
Small snippet.
if (!quiet || errno == ENOMEM)
warn(_("%s: swapoff failed"), orig_special);
return -1;
In my opinion, your workload increases your RAM demand. You are running a workload that requires more memory. Usage of the entire swap indicates that. Also, changing swappiness to 1 might not be a wise decision. Setting swappiness to 1 does not indicate that swapping will not be done. It just indicates how aggressive kernel will be in respect of swapping, it does not eliminate swapping. Swapping will happen if needs to be done.
Also, I don't know why you are trying to disable swap. Unless you have tons and tons of RAM, you should not disable swap.
Of course, you can reboot and swap usage will be zero then. And you can safely swapoff then. But, that doesn't solve the problem in long term.
Would you mind, posting the /proc/meminfo output.
ls -l /dev will give you the major and minor numbers, e.g.
crw-rw---- 1 root dialout 4, 64 Apr 4 07:54 /dev/ttyS0
has major number 4 and minor number 64.
Then you can look at /proc/devices to look up the major number. In this example we have a character device (c at the start of the line) with major number 4, and in /proc/modules we find
Character devices:
...
4 tty
4 ttyS
Allocation of minor numbers is device-dependent.
Some devices are driven from core kernel code (e.g. tty), whereas others are managed by loadable modules (e.g. rfcomm). You could try looking in /proc/modules for a matching module; alternatively look in /proc/kallsyms for the module name. You'll get lots of results, but the key thing to look for is the presence or absence of a string in square brackets. For example, grep tty /proc/kallsyms gives
0000000000000000 t tty_drivers_open
0000000000000000 t show_tty_range
0000000000000000 t show_tty_driver
...
whereas grep rfcomm /proc/kallsyms gievs
0000000000000000 t rfcomm_apply_pn [rfcomm]
0000000000000000 t rfcomm_dlc_debugfs_open [rfcomm]
0000000000000000 t rfcomm_dlc_debugfs_show [rfcomm]
[rfcomm] indicates that the code is in the rfcomm module, whereas tty is in the kernel itself and not in a module, so nothing appears in square brackets.
This method is not definitive but should give you some idea as to where the controlling code lives.
Best Answer
The data returned by
stat(the file's metadata) is cached like any other filesystem data. If you accessed it recently enough for it to be still in the cache, then subsequent accesses are faster, until something else replaces it in RAM.Accessing a file's content does not load its metadata into memory (or vice versa).
The
statcheck costs a little extra (very little if the metadata is in cache, but still a little). Whether this compensates the potential extra processing depends on how much processing you'd be doing and on your IO/CPU saturation ratio.