[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20071217133053.508dbab0@the-village.bc.nu>
Date: Mon, 17 Dec 2007 13:30:53 +0000
From: Alan Cox <alan@...rguk.ukuu.org.uk>
To: Steven Winikoff <smw@...or.concordia.ca>
Cc: linux-kernel@...r.kernel.org,
Sheila Ettinger <sheilae@...or.concordia.ca>,
Tan Bui <tan@...or.concordia.ca>,
Tao Wang <taow@...or.concordia.ca>,
Gillian Roper <groper@...or.concordia.ca>,
Sylvain Robitaille <syl@...or.concordia.ca>
Subject: Re: 2.6.23.8: OOM killer kills wrong jobs
> ...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 majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists