Re: [RFC PATCH v5 6/8] drivers: vmware: balloon - report inflated memory

From: Alexander Atanasov
Date: Fri Oct 21 2022 - 03:25:27 EST


On 21.10.22 9:50, Nadav Amit wrote:
On Oct 19, 2022, at 12:56 PM, Alexander Atanasov <alexander.atanasov@xxxxxxxxxxxxx> wrote:

Update the inflated memory in the mm core on change.

Signed-off-by: Alexander Atanasov <alexander.atanasov@xxxxxxxxxxxxx>
---
drivers/misc/vmw_balloon.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/drivers/misc/vmw_balloon.c b/drivers/misc/vmw_balloon.c
index 91d4d2a285c5..3bfd845898f5 100644
--- a/drivers/misc/vmw_balloon.c
+++ b/drivers/misc/vmw_balloon.c
@@ -1507,6 +1507,7 @@ static void vmballoon_work(struct work_struct *work)
queue_delayed_work(system_freezable_wq,
dwork, round_jiffies_relative(HZ));

+ balloon_set_inflated_free(atomic64_read(&b->size) << 2);
}

I don’t like it in general (I think that something like that should go into
some common infra).

My goal is to create that infra, sure there is a place for improvement.
I think of it as a commit point so plugging it into something existing does not fit or at least i don't see how.

But more concretely there are at least 2 problems here. First, queueing the
work should come last. Second, there are other places that change the
balloon size (e.g., vmballoon_reset()), which are not handled by this patch.

If you added calls to balloon_set_inflated_free() from these places, you can
get races while calling balloon_set_inflated_free() and the last value that
would be latched would be the wrong one. I don’t see anything in the logic
or comments that clarify how something like that should be resolved.



Ok,I will move it before the enqueue call.
But are you sure about this the reset?
vmballoon_reset(...) is called only from vmballoon_work(...) which does the update ? what i am missing?


--
Regards,
Alexander Atanasov