[lkml]   [2000]   [Mar]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Endless overcommit memory thread.
In <Pine.LNX.4.21.0003241723220.793-100000@asdf.capslock.lan> Mike A. Harris ( wrote:
> I've been reading bits and pieces of this whole thread for a
> while now, and have finally come up with an opinion. I think
> that overcommit should be an option which defaults to
> off. Here's why:

> If something allocates memory and then later goes to use it and
> dies, that is just plain wrong. If malloc says the memory is
> avail, and allocates it, then it should be there.

It'll be there if system will have memory. There are NO way to cook up
situation where system working Ok without overcommiting and not working Ok
with overcommiting so what the deal ? If you want to limit something you
need quotas not non-overcommiting.

> Define "allocate". I define it with respect to memory allocation
> as an app beign allocated or GIVEN a requested amount of memory
> to use, and guaranteed that that memory exists and is available
> for usage.

This is not how malloc works. This is how calloc works :-)

> The reason for overcommit in the first place, and correct me if
> I'm wrong here - is because some applications allocate more
> memory than they really end up using.

Yes. Just 100% of existing applications doing it (ok, ok, ok may be just
99%). Why ? It's simple: there are 8MiB stack, you know. And only small
amount of that stack is used by typical application. And fork. And shared
memory segments (usually application will allocate big shared memory
segment "just in case"). And so on.

> If an application allocates a large amount of memory and then
> does not use it, is the app not broken as designed? I say FIX

Go and fix [almost] ALL existing applications. Then come back.

> Can someone please explain to me how and why an app would
> allocate a large amount of memory and then not use it?

See above. ALL applications (exceptions are few and rare) are allocating
8 MiB of memory (stack) and then not using it fully. Applications with fork
and shared memory are other examples.

> Please give specific examples since I can't fathom the reason.

Press tab twice and bash will happily show you few hundreds applications with
this behaviour.

> I think an app that requests a lot of memory and then doesn't use it is
> BAD - broken as designed. I can see legitimate allocation of
> SMALL amounts of unused memory as speculation in time critical
> code, or for optimization, etc.. but not large amounts.

Hmm. 8MiB does not look large at first but then EACH AND EVERY application
need it! And typically shared segment is created few MiBs in size "just in
case". Grand total for typical system is significant.

> Please correct me if I'm wrong. Either way it should be tuneable
> and disableable.

As far as almost all aplications out there are not using all requested memory
I see no reason to disable overcommit.

> I felt that since I had to download 20Mb of this thread this
> week that I'd throw in my $0.02 as well. ;o)

Too bad you just downloaded it and not read it :-/ All this about stack, shared
memory and so on was said already.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:57    [W:0.100 / U:20.868 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site