Arjan van de Ven wrote:
> On Sat, 2005-12-31 at 17:02 +0300, Al Boldi wrote:
> > Shouldn't it be possible to disable overcommit completely, thus giving
> > kswapd a break from running wild trying to find something to swap/page,
> > which is the reason why the system gets unstable going over 95% in your
> > example.
>
> shared mappings make this impractical. To disable overcommit completely,
> each process would need to account for all its own shared libraries, eg
> each process gets glibc added etc. You'll find that on any
> non-extremely-stripped system you then end up with much more memory
> needed than you have ram.
Are you implying shared maps are implemented by way of overcommitting?
Really, overcommit is an add-on feature like swapping, only overcommit is
free because it's a lier. So removing an add-on feature should not affect
the underlying system in any way, such as shared mappings or swapping.
It should be possible to allow swapping to handle all memory requests
exceeding physical RAM. OverCommit should be a tuning option for those who
like to live on the edge, because it really is a gamble.
In the case where swap = physical RAM and overcommit_ratio = 0, the kernel is
in effect hiding the fact that it is overcommitting.
Can you see the overhead involved here?
Thanks for your input!
--
Al
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
