|
|
|
|
|
|
by dozzie
3072 days ago
|
|
|
> (1) The kernel can predict which pages the user will "almost never touch." > I disagree with (1). [...] The kernel does not have sufficiently detailed knowledge of the process's purpose or access patterns. You're in for quite a surprise, particularly on desktop. I have a number of
processes with some pages swapped out, and I see no impact on interacting
with the said processes. Firefox, gDesklets, a volume changer, and several
instances of rxvt are among them. > (2) Mispredicting which pages will be "almost never touched" is of relatively low cost. > I also disagree with (2). The consequences of getting these predictions wrong seem to be very bad. Only in the case of repeated mispredictions, which only happens if you
really have low RAM and are on a good way to invoke OOM killer anyway. With
(1) being quite accurate (mainly because swapping out unused pages is not that
aggressive), (2) magically becomes true as well. |
|
|
Is an appreciable amount of RAM freed up here? I was under the impression that Firefox churned through whatever it allocated (garbage-collected Javascript VM) and rxvt had a very small footprint, most of which is code shared among all of your rxvt instances.
>> I also disagree with (2). The consequences of getting these predictions wrong seem to be very bad. > > Only in the case of repeated mispredictions, which only happens if you really have low RAM and are on a good way to invoke OOM killer anyway.
Even if things were as rosy as you suggest, isn't that my point? Better that the OOM killer cleans something up than I bounce the machine and clean everything up. That said, the OOM killer won't necessarily run anytime soon:
I just spun up a VM with 1GB of memory and 1GB of swap. 'time ssh guest echo hello' from the host usually takes anywhere from 140ms to 1.2s. I wrote a C program that allocates a gigabyte (in two 512MB pieces) and churns it through swap by writing to random bytes. 'time ssh guest echo hello' now takes 4-8 seconds. The oom killer didn't run once in the five minutes I ran the swap-churning process. Setting /proc/sys/vm/swappiness to 0 didn't change the symptoms; 'time ssh guest echo hello' still takes 4-8 seconds. This is on Linux 4.9.65.
If I crank the number of churning threads up from 1 to 8, the one 'time ssh guest echo hello' I tried took 33 seconds. I am not patient enough to see what happens with 64 churning threads, which is entirely reasonable, but I would expect the latency involved in rescuing the machine to cause any reasonable administrator to simply bounce it.
In this workload, the kernel is consistently failing to predict which pages are unimportant; the mispredictions are expensive; the RAM saved by swapping out bash, sshd, and killall (or whatever) is negligible; and the important work of allowing remote login to diagnose and clean up the mess is held up unconscionably long to make room for what, in practical instances, is a user error.
I did a 'swapoff -a' and ran the same C program and it gets killed almost immediately.