Re: overcommit stuff

[Hugh Dickins <hugh@veritas.com>]

On Sat, 21 Sep 2002, Martin J. Bligh wrote:
> 
> > The usual tricks for amortising this counter's cost have (serious)
> > accuracy implications.
> 
> Well, seems it's a rough guess anyway ... at least it's vastly
> inaccurate in one direction (pessimistic).

Yesss.  I don't think it matters much if it's somewhat inaccurate
(the half-of-memory thing is just pulled out of a hat anyway, isn't
it? and there's no accounting for taste^Hthe kernel's memory usage,
just a hope that it won't go over half).

But it would be very wrong to introduce any indeterminacy in the
calculations, such that the numbers might progressively drift
further and further away from what's right.  That's one of the
reasons it ends up so pessimistic, because it would be impossible
(or too costly) to do the accounting otherwise.

> I was thinking of moving the update in vm_enough_memory under
> the switch for what type of overcommit you had, and doing something
> similar for the other places it's updated. I suppose that would do
> unfortunate things if you turned overcommit from 1 to something
> else whilst the system was running though ... not convinced that's
> a good idea anyway OTOH.

It is intended that you should be able to switch commit modes while
running.  There is one hole there that we've not got around to
plugging yet, the handling of MAP_NORESERVE, but otherwise I believe
it makes sense: please don't take that away.

I like to see those Committed_AS numbers (though I don't care for
the "_AS" prefix), even though I run loose.

Hugh

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/