> ...but I've run into a situation in which a system on which I *have* set > no overcommit is being blasted by the OOM killer anyway.
Looks like the kernel is eating all the resources needed. > Linux babyalcor 2.6.23.1 #1 SMP Fri Oct 26 15:35:18 EDT 2007 \ > i686 Dual Core AMD Opteron(tm) Processor 280 AuthenticAMD GNU/Linux 32bit kernel, 16GB of RAM. No suprise I'm afraid. Handling 16GB on a 32bit kernel, which has to manage it all through a small addressible memory window is right on the limit of what the standard kernel will handle (8GB is probably as high as I would go). The no overcommit code ensures that user space doesn't overcommit, but the kernel can get itself short of low memory resources on a big box with 32bit kernels very easily. (In 64bit mode the CPU can address all the memory directly so the problem vanishes). You will *probably* get stable 16GB with the vendor tuned enterprise kernels (RHEL, CentOS etc), or run a 64bit kernel and then the kernel isn't trying the software equivalent of managing a filing cabinet through the keyhole. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
