"It" being vm_committed_space.

The problem is that it's read from frequently, as well as
updated frequently.  So we would still have problems when
we have to reach across and fish the cpu-local counters
out of remote corners of the machine all the time.

Not if you set overcommit = 1, as far as I can see.

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).
 

I am planning on sitting down and working out exactly what we're
trying to account here - presumably there's another way.  Just
havent got onto it yet.

Worst come to worst, we can hide it inside CONFIG_NOT_WHACKOMATIC
I guess.

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.

M.

--
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/