Received-SPF: pass (google.com: domain of linux-kernel+bounces-146171-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Message-ID: <c88b999f-39f9-4771-bb28-b6b0cd5ba22c@bytedance.com>
Date: Tue, 16 Apr 2024 11:20:19 +0800
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Re: [RFC 0/3] Improve memory statistics for virtio balloon
To: David Hildenbrand <david@redhat.com>, linux-kernel@vger.kernel.org,
 linux-mm@kvack.org, virtualization@lists.linux.dev
Cc: mst@redhat.com, jasowang@redhat.com, xuanzhuo@linux.alibaba.com,
 akpm@linux-foundation.org
References: <20240415084113.1203428-1-pizhenwei@bytedance.com>
 <ee1ac0fb-daf7-4aea-b07e-f8879b6b860b@redhat.com>
Content-Language: en-US
From: zhenwei pi <pizhenwei@bytedance.com>
In-Reply-To: <ee1ac0fb-daf7-4aea-b07e-f8879b6b860b@redhat.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 4/15/24 23:01, David Hildenbrand wrote:
> On 15.04.24 10:41, zhenwei pi wrote:
>> Hi,
>>
>> When the guest runs under critial memory pressure, the guest becomss
>> too slow, even sshd turns D state(uninterruptible) on memory
>> allocation. We can't login this VM to do any work on trouble shooting.
>>
>> Guest kernel log via virtual TTY(on host side) only provides a few
>> necessary log after OOM. More detail memory statistics are required,
>> then we can know explicit memory events and estimate the pressure.
>>
>> I'm going to introduce several VM counters for virtio balloon:
>> - oom-kill
>> - alloc-stall
>> - scan-async
>> - scan-direct
>> - reclaim-async
>> - reclaim-direct
> 
> IIUC, we're only exposing events that are already getting provided via 
> all_vm_events(), correct?
> 

Yes, all of these counters come from all_vm_events(). The 'alloc-stall' 
is summary of several classes of alloc-stall. please see '[RFC 2/3] 
virtio_balloon: introduce memory allocation stall counter'.

> In that case, I don't really see a major issue. Some considerations:
> 
> (1) These new events are fairly Linux specific.
> 
> PSWPIN and friends are fairly generic, but HGTLB is also already fairly 
> Linux specific already. OOM-kills don't really exist on Windows, for 
> example. We'll have to be careful of properly describing what the 
> semantics are.
> 

I also notice FreeBSD supports virtio balloon for a long time, 'OOM 
kill' is used on FreeBSD too.(LINK: 
https://klarasystems.com/articles/exploring-swap-on-freebsd/)

> (2) How should we handle if Linux ever stops supporting a certain event 
> (e.g., major reclaim rework). I assume, simply return nothing like we 
> currently would for VIRTIO_BALLOON_S_HTLB_PGALLOC without 
> CONFIG_HUGETLB_PAGE.
> 

Luckily, virtio balloon stats schema is tag-value style. This way would 
be safe enough.


Suggestions in patch [1-3] are good, I'll fix them in the next version 
if this series is acceptable.

-- 
zhenwei pi