Messages in this thread | | | Date | Mon, 02 Nov 2009 20:56:24 +0100 | From | Vedran Furač <> | Subject | Re: Memory overcommit |
| |
Andrea Arcangeli wrote:
> On Fri, Oct 30, 2009 at 03:41:12PM +0100, Vedran Furač wrote: >> Oh... so this is because apps "reserve" (Committed_AS?) more then they >> currently need. > > They don't actually reserve, they end up "reserving" if overcommit is > set to 2 (OVERCOMMIT_NEVER)... Apps aren't reserving, more likely they > simply avoid a flood of mmap when a single one is enough to map an > huge MAP_PRIVATE region like shared libs that you may only execute > partially (this is why total_vm is usually much bigger than real ram > mapped by pagetables represented in rss). But those shared libs are > 99% pageable and they don't need to stay in swap or ram, so > overcommit-as greatly overstimates the actual needs even if shared lib > loading wouldn't be 64bit optimized (i.e. large and a single one).
Thanks for info!
>> A the time of "malloc: Cannot allocate memory": >> >> CommitLimit: 3364440 kB >> Committed_AS: 3240200 kB >> >> So probably everything is ok (and free is misleading). Overcommit is >> unfortunately necessary if I want to be able to use all my memory. > > Add more swap.
I don't use swap. With current prices of RAM, swap is history, at least for desktops. I hate when e.g. firefox gets swapped out if I don't use it for a while. Removing swap decreased desktop latencies drastically. And I don't care much if I'll loose 100MB of potential free memory that could be used for disk cache...
Regards.
Vedran
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |