vm_object_coalesce(): do not account holes twice

[kib]

Summary

alc wrote:
Suppose that the object is OBJ_ONEMAPPING and that we, in fact,
have a single mapping to it. Then, we punch a hole in that mapping.
vm_map_entry_delete() only subtracts from the object's charge when
we shrink the size of the object. Now, suppose that we perform
mmap(MAP_ANON) to reallocate some of the hole. Aren't we going to add to
the charge here, even though vm_map_entry_delete() never subtracted from
the charge for the hole that was created?

Only account the change in the charged object size that was added to it.
Also remove ifdef-ed block that tried to correct charge and that is
not needed.

Noted by:       alc

[markj]

vm_map_entry_delete() only subtracts from the object's charge when we shrink the size of the object.

Isn't that the bug? That is, shouldn't vm_map_entry_delete() subtract the size of the hole from the charge if the object has only one mapping?

[kib]

In D53965#1233222, @markj wrote:

vm_map_entry_delete() only subtracts from the object's charge when we shrink the size of the object.

Isn't that the bug? That is, shouldn't vm_map_entry_delete() subtract the size of the hole from the charge if the object has only one mapping?

It can be interpreted this way, but fixing it this way is IMO impossible. We do not track dead ranges in the object, but we must do it to handle the case if the range is revived, e.g. by coalescing. Right now the charge is more or less the max of the used range end. Sometimes I even think that object->charge was redundant, and just a flag like charged should mean that whole object size is accounted to object->cred.

IMO the fix I propose is in line with other parts of the swap accounting code.

[alc]

This change is now similar to D43263. Abandon this one?

[kib]

In D53965#1241683, @alc wrote:

This change is now similar to D43263. Abandon this one?

I suspect that either the comment is mis-directed, or the referenced review has the wrong number.

Indeed, it should point to D54263

[alc]

In D53965#1241686, @kib wrote:

In D53965#1241683, @alc wrote:

This change is now similar to D43263. Abandon this one?

I suspect that either the comment is mis-directed, or the referenced review has the wrong number.

Indeed, it should point to D54263

Yes.