It's good to hear that you found this article to be useful. Please don't be hesitate to write further comments about it.
About FF (Firefox) got killed instead of
loop-calloc, I have a pretty good guess that FF had bigger VM size than
loop-calloc when OOM killer was working in your case. Recall that running time is just one of the killer's criteria, so to predict which application get killed, you need to carefully check all those 7 criterias I have mentioned in the article.
I have tried to mimic your case, simply by doing
tail -f /dev/zero while FF 1.0.4 was running. Instead of killing
tail right away, FF was killed together with other application such as KDE panel and KMail.
Top reported that FF consumed ~33MB of virtual memory while free+reclaimable RAM was about ~30 MB before loop-calloc was started.
My suggestion, instead of looking ways to disable OOM killer, is to use
ulimit whenever you want to start a memory hogger application. Start a shell (possibly via xterm or Konsole),
ulimit -v <some amount of memory> and start the application after that. Assuming the application does proper checking after
malloc() and strict overcommit is enabled, there is no need for OOM-killer to randomly kills application..which is in your case, ended up with killing innocent FF.