From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f45.google.com (mail-ej1-f45.google.com [209.85.218.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B9836389E10 for ; Mon, 19 Jan 2026 16:30:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768840249; cv=none; b=NHXtJnGek78DbwIkiFIYJfKFESywMZc5XMI7X+ro+szTDVUNIMJ+/JHJMnYp+pTgMbk4wygRVdB4nA/ofT33XJRuJSczGFWARLrAxwRLxGaCMie22XQ51hW0sm3IzPe/YRMuJnHXfP3sMFl6jyRDU5/IoCwjDOu+CGa5sLGXBmA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768840249; c=relaxed/simple; bh=74nuZh3CRHnlUvBAbWZ6tYHKEa5PfTvtDxqJmYiZgE8=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=mx3xk8U6GgP88E0ZrQvHqnWCRkDWhPL6yVfNs/a5txWGaLPTTJnexCKpT/Wfav4iejizqTuSUq4Hxb4K7BMCjcOGMI5J/WJuleghfj0uCIpuav/C6IeOWwXZ5KqoQPRHPRFLhMjOTGZ4HaZKdhv/AahsyMgAxoIH7broMBgA4AA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=hhdXKBtp; arc=none smtp.client-ip=209.85.218.45 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="hhdXKBtp" Received: by mail-ej1-f45.google.com with SMTP id a640c23a62f3a-b871cfb49e6so726443266b.1 for ; Mon, 19 Jan 2026 08:30:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768840246; x=1769445046; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=MAx9ToKLl7t8y9PiSc/w47xhuek7x5/AEgqS5Sqqu4g=; b=hhdXKBtpZLdoJRvoO/B4NAzxx2DUIaU1WB7jtk8enKX8whJ9gylbeK/3VXIKHho4jU cFaCxP5FtY3jIJRmAMFJ/ab6NnQsk4dv4XTiLVWT5n/KCPiklcOX9opeUgegKo40ZSo1 wcyHD8JNrILs+MKPcW5HxRErLEQKi7eZVPO2/kCufG64FzuvS9c1NsZOU6MrtwNvc+wJ 8yRU8BWErJvtvsyvDtgVN0AOPDq5vPOFJOs43cUUQWR3krTP05zvpXBalIkLgG6RZ3mN 01YxQN5Mp9ZC3V4OEsdwXwUr5n/vglbChr0Px8vuAV5z2pZ+//E6h4jDLKEkTiF0oGZU M0sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768840246; x=1769445046; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=MAx9ToKLl7t8y9PiSc/w47xhuek7x5/AEgqS5Sqqu4g=; b=YYZwsrcnGbHRjSYwJwtUWicjkdsVfWqb3xLF5fYnnmvcKXM6bU6m5oYaekqxI42iLq CNLJhUnSv5EJ/eZobgkrj55JMZGh3u1LFbWG9WVrEjmEtHyGPYuNXnjqxm7UD+of6hhM 10j+nuErtp+chq4Ma075/Zeimhksh0szBPLqd4kBB/qxyIdSeq8+m/fFPmfDjbh16t1z +kS/fcykT+fsTVh5PNAG9E4QvgTTap9ano/+M0WisC3j/ZhKdzZzj5aaoRv2Rs/6GSy0 Ok9jP9JK3AFHohm7iCQ5Wz0E3f/O8Q5VLH67egsB3C5Bj2xoC6SrbCv8X7B1TH702cUA KPeg== X-Forwarded-Encrypted: i=1; AJvYcCVLjHxMDxSkAoA24gTMEIgGRq7zBdnodWv9xOiejvxbvr+5taYdFBUxBH7yWlAzDzFUQCoJJS0hWNoIsgI=@vger.kernel.org X-Gm-Message-State: AOJu0YxY/nUiILF+gWHU35UqKdj+vWlhw+rhxKSw6JsK/NKdff0eH/Mp Dd13GG+GG8uv1vi0b2IwoN1TpW8lhX29+VknpsWBFKttaVUD3cpJkJ6Y X-Gm-Gg: AY/fxX6MQ6JDhkSKBzjk9nm2DU1nVETE/DauKiGOZCTBLtGzCOhzpPEOWkHX+oZylwI OgGZepV97g5Xu/LQLKeNDlpq6a7HotQwU46mUPv0EMeoUCo/8UH8ethQKp+8Mxq3hpAHWv69niI 7tXPavrkXvTjfEuJ56+ChU5UQe6SNEM7MbOdqMbfw6vYuivs7VMDOpy5HaR/kmHqlJqsi13ssYI 9anSDNFlGIOJ0ws3vZQimiPzogWzGrT7ER5+XEOI8HSNpZmecCa9IvAflD41I0NG7Z0SIeMSvS0 RQyY6N96Qk8HFnCa08aJzr5op78CRINcWmembXfholeriqNIsRqWqQDUX4ll0FrFoWQwHy84QRF 7ip4JrsIJ7S1PwOoGTGAIN776bscI/9Hvnbv/qqutr+gJPG1fV0NoElOt1PMH/fMq4Xi7Gf7Qba WRAqmaBx4gDo12+2nOs+J2mJNq1P27dd0i5I/my+8dpQ== X-Received: by 2002:a17:906:4fd0:b0:b7c:e320:5250 with SMTP id a640c23a62f3a-b87968d1745mr879203466b.7.1768840245683; Mon, 19 Jan 2026 08:30:45 -0800 (PST) Received: from [10.24.66.11] ([15.248.2.27]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b8795169d30sm1167827566b.25.2026.01.19.08.30.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 19 Jan 2026 08:30:45 -0800 (PST) Message-ID: Date: Mon, 19 Jan 2026 16:30:44 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH] virtio_balloon: Support wait on ACK for hinting To: "David Hildenbrand (Red Hat)" , mst@redhat.com, jasowang@redhat.com Cc: xuanzhuo@linux.alibaba.com, eperezma@redhat.com, virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, kalyazin@amazon.co.uk, xmarcalx@amazon.co.uk, jackabt@amazon.com References: <20260119154236.39412-1-jackabt.amazon@gmail.com> <6c3f8061-302e-40c1-829b-2f8555bee70c@kernel.org> Content-Language: en-US From: "Thomson, Jack" In-Reply-To: <6c3f8061-302e-40c1-829b-2f8555bee70c@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 19/01/2026 3:50 pm, David Hildenbrand (Red Hat) wrote: > On 1/19/26 16:42, Jack Thomson wrote: >> From: Jack Thomson >> >> This RFC patch adds a new virtio feature for the virtio-balloon driver >> during free page hinting, which will wait on device ack before >> committing the range to the free_page_list. The reason for the change is >> it allows the device to modify this range without it being reclaimed >> from the free_page_list before the ack is sent. As expected, testing >> shows this adds overhead to the hinting run duration, increasing it by >> ~30% with our Firecracker setup. Currently free page hinting is used >> mainly for live migration, but this would open it up for a new use-case. >> >> We would like to leverage this with MADV_DONTNEED to reduce RSS of a >> guest. We'd like to use hinting because of the flexibility of control it >> brings compared to reporting, allowing memory to be reclaimed in >> deterministic periods. > > Can you elaborate in more detail why you don't simply use reporting, > like QEMU? Ideally we'd like to use hinting as the API allows us to control when this reclamation takes place so as not to impact active VMs. For example if we know a VM is idle we can reclaim memory but also cancel the reclamation quickly if the VM receives new work (something we can't do quickly with the traditional balloon.) > Could you instead see optimizations being done to reporting that could > make it fly for your use case? One thing that I considered was having reporting running but skip reported ranges during active times. But this may lead to missing reclamation opportunities. > > Hinting is a rather special case thing only used for reducing VM > migration time in QEMU AFAIR. > Yeah, its API allowing direct control was what interested us. With this extension it made a great pairing just needed the synchronisation to make it safe. -- Thanks, Jack