> What should have happened is each of the tasks need only about
> 4k until they actually access something. Since they can't possibly
> access everything at once, we need to fault in pages as needed,
> not all at once. This is what 'overcomit' is, and it is necessary.
I should also mention this is demand paging, not overcommit.
Overcommit is the property of succeeded more allocations than their is
memory in the address space. The idea being that allocations are lazy,
things often do not use their full allocations, etc. etc. as you
mentioned.
It is typical a good thing since it lowers VM pressure.
It is not always a good thing, for numerous reasons, and it becomes
important in those scenarios to ensure that all allocations can be met
by the backing store and consequently we never find ourselves with more
memory committed than available and thus never OOM.
This has nothing to do with paging and resource limits as you say. Btw,
without this it is possible to OOM any machine. OOM is a by-product of
allowing overcommit and poor accounting (and perhaps poor
software/users), not an incorrectly configured machine.
Robert Love
-
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/