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

  Update the inflated memory in the mm core on change.

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

On Wed, Oct 19, 2022 at 12:56:18PM +0300, Alexander Atanasov wrote:
> Update the inflated memory in the mm core on change.

That says what this does, but not why it is needed.

Please expand on this.

Also, is this actually fixing a bug?  Is it a new feature?  Something
else?

thanks,

greg k-h
  

On 19.10.22 13:26, Greg Kroah-Hartman wrote:
> On Wed, Oct 19, 2022 at 12:56:18PM +0300, Alexander Atanasov wrote:
>> Update the inflated memory in the mm core on change.
> 
> That says what this does, but not why it is needed.
> 
> Please expand on this.
> 
> Also, is this actually fixing a bug?  Is it a new feature?  Something
> else?

The whole series is about adding a new feature - providing access to the 
balloon inflated memory amount - it's in the cover letter. Should I 
repeat it for every driver that implements it?

I've organized it classically:
- prepare
- add infra
- use the infra

What can I improve here?
  

On Wed, Oct 19, 2022 at 01:38:13PM +0300, Alexander Atanasov wrote:
> On 19.10.22 13:26, Greg Kroah-Hartman wrote:
> > On Wed, Oct 19, 2022 at 12:56:18PM +0300, Alexander Atanasov wrote:
> > > Update the inflated memory in the mm core on change.
> > 
> > That says what this does, but not why it is needed.
> > 
> > Please expand on this.
> > 
> > Also, is this actually fixing a bug?  Is it a new feature?  Something
> > else?
> 
> The whole series is about adding a new feature - providing access to the
> balloon inflated memory amount - it's in the cover letter. Should I repeat
> it for every driver that implements it?

Each commit needs to justify why it is needed on its own.  You do not
provide the needed information here at all to be able to review and
understand if this commit is even correct or needed.

thanks,

greg k-h
  

On 19.10.22 13:49, Greg Kroah-Hartman wrote:
> On Wed, Oct 19, 2022 at 01:38:13PM +0300, Alexander Atanasov wrote:
>> On 19.10.22 13:26, Greg Kroah-Hartman wrote:
>>> On Wed, Oct 19, 2022 at 12:56:18PM +0300, Alexander Atanasov wrote:
>>>> Update the inflated memory in the mm core on change.
>>>
>>> That says what this does, but not why it is needed.
>>>
>>> Please expand on this.
>>>
>>> Also, is this actually fixing a bug?  Is it a new feature?  Something
>>> else?
>>
>> The whole series is about adding a new feature - providing access to the
>> balloon inflated memory amount - it's in the cover letter. Should I repeat
>> it for every driver that implements it?
> 
> Each commit needs to justify why it is needed on its own.  You do not
> provide the needed information here at all to be able to review and
> understand if this commit is even correct or needed.

Ok, understood. I will keep that in mind. Thanks.
  

On Oct 19, 2022, at 12:56 PM, Alexander Atanasov <alexander.atanasov@virtuozzo.com> wrote:

> Update the inflated memory in the mm core on change.
> 
> Signed-off-by: Alexander Atanasov <alexander.atanasov@virtuozzo.com>
> ---
> 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).

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.
  

On 21.10.22 9:50, Nadav Amit wrote:
> On Oct 19, 2022, at 12:56 PM, Alexander Atanasov <alexander.atanasov@virtuozzo.com> wrote:
> 
>> Update the inflated memory in the mm core on change.
>>
>> Signed-off-by: Alexander Atanasov <alexander.atanasov@virtuozzo.com>
>> ---
>> 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?
  

On Oct 21, 2022, at 10:25 AM, Alexander Atanasov <alexander.atanasov@virtuozzo.com> wrote:

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

My bad. But when the module is unloaded, vmballoon_pop() is called.
  

On 21.10.22 10:31, Nadav Amit wrote:
> On Oct 21, 2022, at 10:25 AM, Alexander Atanasov <alexander.atanasov@virtuozzo.com> wrote:
> 
>>
>> 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?
> 
> My bad. But when the module is unloaded, vmballoon_pop() is called.

Yes, i missed the unload -  i will just set it to zero there.