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

Message ID 20221019095620.124909-7-alexander.atanasov@virtuozzo.com
State New
Headers
Series None |

Commit Message

Alexander Atanasov Oct. 19, 2022, 9:56 a.m. UTC
  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(+)
  

Comments

Greg KH Oct. 19, 2022, 10:26 a.m. UTC | #1
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
  
Alexander Atanasov Oct. 19, 2022, 10:38 a.m. UTC | #2
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?
  
Greg KH Oct. 19, 2022, 10:49 a.m. UTC | #3
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
  
Alexander Atanasov Oct. 19, 2022, 11:06 a.m. UTC | #4
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.
  
Nadav Amit Oct. 21, 2022, 6:50 a.m. UTC | #5
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.
  
Alexander Atanasov Oct. 21, 2022, 7:25 a.m. UTC | #6
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?
  
Nadav Amit Oct. 21, 2022, 7:31 a.m. UTC | #7
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.
  
Alexander Atanasov Oct. 21, 2022, 8:02 a.m. UTC | #8
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.
  

Patch

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);
 }
 
 /**