News for hackers. Stuff that matters.
Re:Linux memory overcommit (compared to airlines selling tic... by acqq on Friday May 13, 2011 @10:59AM (#2544859)
The post linked from the article is really nice:

http://lwn.net/Articles/104185/

"in rare occasions however the amount of fuel was insufficient, and the plane would crash. This problem was solved by the engineers of the company by the development of a special OOF (out-of-fuel) mechanism. In emergency cases a passenger was selected and thrown out of the plane. (When necessary, the procedure was repeated.)"

I always thought that mapping of virtual memory should succeed only if there is enough virtual memory available (i.e. when not in RAM than in page file). Why is the overcommit concept better? Because malloc takes way too much VM unnecessary? Then why not just correcting malloc?

Re:Linux memory overcommit (compared to airlines selling tic... by amalcon on Friday May 13, 2011 @11:16AM (#2544910)
Well, malloc() is very much doing the right thing in a world where (virtual) memory is plentiful. The performance of the program improves substantially, without impacting memory usage that much.

I never understood why the system doesn't do the accounting strictly, even if it waits to actually hand out individual pages. Then, it could give an error on brk() or mmap() when the memory would be "overbooked". Memory "saved" this way would be unusable to other processes, but it would be usable as buffer cache, and fork() would still be fast.

edit: Another possible solution would be a special "out-of-memory" signal. The program could trap that signal and do the right thing with it. The problem with that is that it's difficult to program for out-of-memory conditions. Something as simple as printf() won't work at all, and could cause a signal loop depending on implementation. Given that, almost no programs would do it, so there would be little benefit.

Re:Linux memory overcommit (compared to airlines selling tic... by gsg on Friday May 13, 2011 @12:57PM (#2545276)
Why would you deny allocation requests larger than immediately available physical memory when they could be serviced perfectly well by paging?

On modern systems malloc and friends manage address space, not physical memory. Failure should only be reported if that resource is exhausted.