From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 94400C25B06 for ; Tue, 9 Aug 2022 10:03:57 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 15C8B40585; Tue, 9 Aug 2022 10:03:57 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 15C8B40585 Authentication-Results: smtp2.osuosl.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=cDKrnQXt X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jXAi9Ua9R3w4; Tue, 9 Aug 2022 10:03:55 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [IPv6:2605:bc80:3010:104::8cd3:938]) by smtp2.osuosl.org (Postfix) with ESMTPS id E007540573; Tue, 9 Aug 2022 10:03:54 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org E007540573 Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id 9C130C0033; Tue, 9 Aug 2022 10:03:54 +0000 (UTC) Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 75492C002D for ; Tue, 9 Aug 2022 10:03:52 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 3AFFB4086F for ; Tue, 9 Aug 2022 10:03:52 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 3AFFB4086F Authentication-Results: smtp4.osuosl.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=cDKrnQXt X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDoM763uss2N for ; Tue, 9 Aug 2022 10:03:50 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 1994440867 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by smtp4.osuosl.org (Postfix) with ESMTPS id 1994440867 for ; Tue, 9 Aug 2022 10:03:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1660039428; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=z4S7sEwRZF/s5fONnXF+oN53vWEng4sMiupLFnh9W74=; b=cDKrnQXt5DqRUafsOS3k8cVWjmppXJMXMgC14wvUCiXuNHozpnxHl6q7p+B5wnVKqV1GL2 wZqLFRJWubLM787CKhSZx31WxWN3WjCjTiM9lALa0SYXqBcxwd+eYdnLGqEh3UeVX4v6ag KBORG9DXRVt6jqPo24gau9a1uOo1apY= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-288-R9UYr-4sNLyUhCH8vROpNw-1; Tue, 09 Aug 2022 06:03:46 -0400 X-MC-Unique: R9UYr-4sNLyUhCH8vROpNw-1 Received: by mail-wm1-f69.google.com with SMTP id x17-20020a05600c21d100b003a32dda6577so2152744wmj.7 for ; Tue, 09 Aug 2022 03:03:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:subject:organization:from :references:cc:to:content-language:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc; bh=z4S7sEwRZF/s5fONnXF+oN53vWEng4sMiupLFnh9W74=; b=OhKqX3tWj3WiQj0nnGB5gS7lXSX0JAixKxw9JhYWklsF9s9boSdXnmrpW+M6YcvMiI 7zgeijx8VPwx/BiUY1AeM8FcTpD9jnF1tcxjcsi/Wllno+RiEw6OHmPUC17PeyQiF+gX cROiJMtnIYYtEpOBimLfIdxgc4FHaHuGN2xXuOZR8OAMlE5TxdGxt5LSD3aYDPyAAKsT O31af64mAlViBrs6Eto71BjOZNea/szCI2B9fYFeSKa7M8Ag2YXajsSnhpg3Fj4WQ1EA zoF21gsatrwaXuGyr5kXc9zI8Vrx7Ru3+kA5gAxC8IHElXkMd6Qck4gvZVYDT8rvLqcf 1KAg== X-Gm-Message-State: ACgBeo3Wc4S/j1bn/HPGUs5th8t2h/U+panvcm0FWoIrHdzTkJgNZ6Zu pfaKrHOxXhIHWztQb8xBEQrv8vPCi1NZHsCFuISmbxW2udX4Y7o/D7O/icQ37A80rsGBU48tIsH 6zqW0Gkwqs+O2CWV5PdfCMa9kjDNNSymVf877gy9WXg== X-Received: by 2002:adf:eb4c:0:b0:220:6aaf:ef5e with SMTP id u12-20020adfeb4c000000b002206aafef5emr13314859wrn.488.1660039424622; Tue, 09 Aug 2022 03:03:44 -0700 (PDT) X-Google-Smtp-Source: AA6agR7y5+8/fEMwrlzoSfhLcMgqH5R7lIz5Q92iaf/1I0YI3oGEeG6j/+HbyhSs4Xw/986oaQT4yA== X-Received: by 2002:adf:eb4c:0:b0:220:6aaf:ef5e with SMTP id u12-20020adfeb4c000000b002206aafef5emr13314830wrn.488.1660039424232; Tue, 09 Aug 2022 03:03:44 -0700 (PDT) Received: from ?IPV6:2003:d8:2f15:c300:d2ce:1fb5:2460:179a? (p200300d82f15c300d2ce1fb52460179a.dip0.t-ipconnect.de. [2003:d8:2f15:c300:d2ce:1fb5:2460:179a]) by smtp.gmail.com with ESMTPSA id o24-20020a05600c511800b003a54f49c1c8sm3730714wms.12.2022.08.09.03.03.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 09 Aug 2022 03:03:43 -0700 (PDT) Message-ID: Date: Tue, 9 Aug 2022 12:03:42 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 To: Alexander Atanasov , "Michael S. Tsirkin" , Jason Wang References: <55016ed9-7b3c-c4eb-f5f4-02cfce2191e4@redhat.com> <20220726140831.72816-1-alexander.atanasov@virtuozzo.com> <2d0703da-ae89-7002-f500-300a4b5d206b@redhat.com> <3a5e60e8-a0d2-a1f1-28e9-e0b45069029a@virtuozzo.com> <71e73194-1683-b65f-7b84-c0c719010aef@redhat.com> <2dfad5c8-59d2-69a1-cc4c-d530c12ceea9@virtuozzo.com> <7bfac48d-2e50-641b-6523-662ea4df0240@virtuozzo.com> From: David Hildenbrand Organization: Red Hat Subject: Re: [RFC] how the ballooned memory should be accounted by the drivers inside the guests? (was:[PATCH v6 1/2] Create debugfs file with virtio balloon usage information) In-Reply-To: <7bfac48d-2e50-641b-6523-662ea4df0240@virtuozzo.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Cc: Juergen Gross , Wei Liu , Stefano Stabellini , Stephen Hemminger , Arnd Bergmann , Greg Kroah-Hartman , Haiyang Zhang , linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, kernel@openvz.org, stevensd@chromium.org, Johannes Weiner , Nadav Amit , Boris Ostrovsky , Andrew Morton X-BeenThere: virtualization@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Linux virtualization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: virtualization-bounces@lists.linux-foundation.org Sender: "Virtualization" T24gMDkuMDguMjIgMTE6MzYsIEFsZXhhbmRlciBBdGFuYXNvdiB3cm90ZToKPiBIZWxsbywKPiAK PiBPbiAyLjA4LjIyIDE2OjQ4LCBEYXZpZCBIaWxkZW5icmFuZCB3cm90ZToKPj4+Pgo+Pj4+IElu IGNhc2Ugb2YgSHlwZXItViBJIHJlbWVtYmVyIGEgY3VzdG9tZXIgQlVHIHJlcG9ydCB0aGF0IHJl cXVlc3RlZCB0aGF0Cj4+Pj4gZXhhY3QgYmVoYXZpb3IsIGhvd2V2ZXIsIEknbSBub3QgYWJsZSB0 byBsb2NhdGUgdGhlIEJaIHF1aWNrbHkuCj4+Pj4gWzFdIGh0dHBzOi8vbGlzdHMubGludXhmb3Vu ZGF0aW9uLm9yZy9waXBlcm1haWwvdmlydHVhbGl6YXRpb24vMjAyMS1Ob3ZlbWJlci8wNTc3Njcu aHRtbAo+Pj4+IChub3RlIHRoYXQgSSBjYW4ndCBlYXNpbHkgZmluZCB0aGUgb3JpZ2luYWwgbWFp bCBpbiB0aGUgYXJjaGl2ZXMpCj4+Pgo+Pj4gVk1XYXJlIGRvZXMgbm90LCBYZW4gZG8sIEhWIGRv IChidXQgaXQgZGlkbid0KSAtIFZpcnRpbyBkb2VzIGJvdGguCj4+Pgo+Pj4gRm9yIG1lIHRoZSBj b25mdXNpb24gY29tZXMgZnJvbSBtaXhpbmcgYmFsbG9vbmluZyBhbmQgaG90IHBsdWcuCj4+Cj4+ IEZvciBleGFtcGxlLCBRRU1VIChhbmQgZXZlbiBsaWJ2aXJ0KSBkb2Vzbid0IGV2ZW4gaGF2ZSBi dWlsdCBpbiBzdXBwb3J0Cj4+IGZvciBhbnkga2luZCBvZiBhdXRvbWF0aWMgYmFsbG9vbiByZXNp emluZyBvbiBndWVzdCBtZW1vcnkgcHJlc3N1cmUgKGFuZAo+PiBJJ20gaGFwcHkgdGhhdCB3ZSBk b24ndCBpbXBsZW1lbnQgYW55IHN1Y2ggaGV1cmlzdGljcykuIEFzIGEgdXNlci9hZG1pbiwKPj4g YWxsIHlvdSBjYW4gZG8gaXMgbWFudWFsbHkgYWRqdXN0IHRoZSBsb2dpY2FsIFZNIHNpemUgYnkg cmVxdWVzdGluZyB0bwo+PiBpbmZsYXRlL2RlZmxhdGUgdGhlIGJhbGxvb24uIEZvciB2aXJ0aW8t YmFsbG9vbiwgd2UgY2Fubm90IGRlcml2ZSB3aGF0Cj4+IHRoZSBoeXBlcnZpc29yL2FkbWluIG1p Z2h0IG9yIG1pZ2h0IG5vdCBkbyAtLSBhbmQgd2hldGhlciB0aGUgYWRtaW4KPj4gaW50ZW5kcyB0 byB1c2UgbWVtb3J5IGJhbGxvb25pbmcgZm9yIG1lbW9yeSBob3R1bnBsdWcgb3IgZm9yIG9wdGlt aXppbmcgPiBtZW1vcnkgb3ZlcmNvbW1pdC4KPiAKPiBJcyB0aGUgbGFjayBvZiBwcm9wZXIgaG90 cGx1Zy91bnBsdWcgbGVhZGluZyB0aGUgYWRtaW5zIHRvIHVzZSBpdCBsaWtlIAo+IHRoaXM/CgpZ ZXMuIEVzcGVjaWFsbHkgdW5wbHVnIGlzIHRyaWNreSBhbmQgaGFyZCB0byBnZXQgd29ya2luZyBy ZWxpYWJseSBpbgpwcmFjdGljZSBiZWNhdXNlIG9mIHVubW92YWJsZSBwYWdlcy4gQmFsbG9vbmlu ZyBpcyBhbiBlYXN5IGhhY2sgdG8gZ2V0CnVucGx1ZyBzb21ld2hhdCB3b3JraW5nLgoKRm9yIHJl ZmVyZW5jZTogdW5kZXIgV2luZG93cyBiYWxsb29uaW5nIHdhcyAoYW5kIG1heWJlIHN0aWxsIG1v c3RseSBpcykKdGhlIG9ubHkgd2F5IHRvIHVucGx1ZyBtZW1vcnkgYWdhaW4uIFVucGx1ZyBvZiBE SU1NcyBpcyBub3Qgc3VwcG9ydGVkLgoKPiBJIHJlYWxseSBkb24ndCB1bmRlcnN0YW5kIHdoeSB5 b3UgZG9uJ3QgbGlrZSBhdXRvbWF0aWMgcmVzaXppbmcgLSAKPiBib3RoIEh5cGVyViBhbmQgVk1X YXJlIGRvIGl0ID8KCllvdSBuZWVkIGhldXJpc3RpY3MgdG8gZ3Vlc3Mgd2hhdCB0aGUgZ3Vlc3Qg bWlnaHQgYmUgZG9pbmcgbmV4dCBhbmQKZGVmbGF0ZSBmYXN0IGVub3VnaCB0byBhdm9pZCBhbnkg a2luZCBvZiBPT01zIGluIHRoZSBndWVzdC4gSSBwcmV0dHkKbXVjaCBkaXNsaWtlIHRoYXQgY29u Y2VwdCwgYmVjYXVzZSBpdCBqdXN0IHNjcmVhbXMgdG8gYmUgZnJhZ2lsZS4KCkluIHNob3J0OiBJ IGRvbid0IGxpa2UgYmFsbG9vbmluZywgdG8gbWUgaXQncyBhIHRlY2hub2xvZ3kgZnJvbSBhbmNp ZW50CnRpbWVzIGJlZm9yZSB3ZSB3ZXJlIGFibGUgdG8gZG8gYW55IGJldHRlci4gSW4gY29tcGFy aXNvbiwgSSBkbyBsaWtlCmZyZWUgcGFnZSByZXBvcnRpbmcgZm9yIG9wdGltaXppbmcgbWVtb3J5 IG92ZXJjb21taXQsIGJ1dCBpdCBzdGlsbCBoYXMKc29tZSBkcmF3YmFja3MgKGNhY2hlcyBjb25z dW1pbmcgdG9vIG11Y2ggbWVtb3J5KSwgdGhhdCBwZW9wbGUgYXJlCndvcmtpbmcgb24gdG8gaW1w cm92ZS4gU28gd2UncmUgc3R1Y2sgd2l0aCBiYWxsb29uaW5nIGZvciBub3cgZm9yIHNvbWUKdXNl IGNhc2VzLgoKUGVyc29uYWxseSwgSSBjb25zaWRlciBhbnkgYmFsbG9vbiBleHRlbnNpb25zIChp bmZsYXRlL2RlZmxhdGUsIG5vdAp0aGluZ3MgbGlrZSBmcmVlIHBhZ2UgcmVwb3J0aW5nKSBhIHdh c3RlIG9mIHRpbWUgYW5kIGVmZm9ydCwgYnV0IHRoYXQncwpqdXN0IG15IGh1bWJsZSBvcGluaW9u LiBTbyBJIGtlZXAgcmV2aWV3aW5nIGFuZCBtYWludGFpbmluZyB0aGVtIDspCgo+IAo+PiBBcyBh bm90aGVyIGV4YW1wbGUsIEhWIGR5bmFtaWMgbWVtb3J5IGFjdHVhbGx5IGNvbWJpbmVzIG1lbW9y eSBob3RwbHVnCj4+IHdpdGggbWVtb3J5IGJhbGxvb25pbmc6IHVzZSBtZW1vcnkgaG90cGx1ZyB0 byBhZGQgbW9yZSBtZW1vcnkgb24gZGVtYW5kCj4+IGFuZCB1c2UgbWVtb3J5IGJhbGxvb25pbmcg dG8gbG9naWNhbGx5IHVucGx1ZyBtZW1vcnkgYWdhaW4uCj4gCj4gSGF2ZSBib3RoIGFzIGFuIG9w dGlvbnMgLSBtaW4vbWF4IG1lbW9yeSAsIHBlcmNlbnRhZ2UgZnJlZSB0byBrZWVwIGFzIAo+IG1p bmltdW0sIGZpeGVkIHNpemUgYW5kIGhhdmUgaG90IGFkZCAtIGtpbmQgb2YgaG90IHBsdWcgdG8g Z28gYWJvdmUgCj4gaW5pdGlhbCBtYXggLSB0cmllcyB0byBtYW5hZ2UgaXQgaW4gZHluYW1pYyB3 YXkuCj4gCj4+IFRoZSBWTVdhcmUgYmFsbG9vbiBpcyBhIGJpdCBzcGVjaWFsLCBiZWNhdXNlIGl0 IGFjdHVhbGx5IHVzdWFsbHkKPj4gaW1wbGVtZW50cyBkZWZsYXRlLW9uLW9vbSBzZW1hbnRpY3Mg aW4gdGhlIGh5cGVydmlzb3IuIElJUkMsIHRoZQo+PiBoeXBlcnZpc29yIHdpbGwgYWN0dWFsbHkg YWRqdXN0IHRoZSBiYWxsb29uIHNpemUgYmFzZWQgb24gZ3Vlc3QgbWVtb3J5Cj4+IHN0YXRzLCBh bmQgdGhlcmUgaXNuJ3QgcmVhbGx5IGFuIGludGVyZmFjZSB0byBtYW51YWxseSBzZXQgdGhlIGJh bGxvb24KPj4gc2l6ZSBmb3IgYW4gYWRtaW4uIEJ1dCBJIG1pZ2h0IGJlIHdyb25nIHJlZ2FyZGlu ZyB0aGUgbGF0dGVyLgo+IAo+IEZvciBtZSB0aGlzIGlzIHdoYXQgbWFrZXMgc2Vuc2UgLSB5b3Ug aGF2ZSBhIGxpbWl0ZWQgYW1vdW50IG9mCj4gcGh5c2ljYWwgUkFNIHRoYXQgeW91IHdhbnQgdG8g YmUgdXNlZCBvcHRpbWFsbHkgYnkgdGhlIGd1ZXN0cy4KPiBXYWl0aW5nIGZvciB0aGUgYWRtaW4g dG8gYWRqdXN0IHRoZSBiYWxsb29uIHdvdWxkIG5vdCBnaXZlIHZlcnkKPiBvcHRpbWFsIHJlc3Vs dHMuCgpFeGFjdGx5LiBGb3IgdGhlIHVzZSBjYXNlIG9mIG9wdGltaXppbmcgbWVtb3J5IG92ZXJj b21taXQgaW4gdGhlCmh5cGVydmlzb3IsIHlvdSB3YW50IGRlZmxhdGUtb24tb29tIHNlbWFudGlj cyBpZiB5b3UgZ28gd2l0aCBiYWxsb29uCmluZmxhdGlvbi9kZWZsYXRpb24uCgo+IAo+Pgo+Pj4K Pj4+IEJhbGxvb25pbmcgaXMgbGlrZSBhIGhlYXAgaW5zaWRlIHRoZSBndWVzdCBmcm9tIHdoaWNo IHRoZSBob3N0IGNhbgo+Pj4gYWxsb2NhdGUvZGVhbGxvY2F0ZSBwYWdlcywgaWYgdGhlcmUgaXMg YSBtZWNoYW5pc20gZm9yIHRoZSBndWVzdCB0byBhc2sKPj4+IHRoZSBob3N0IGZvciBtb3JlL3Rv IGZyZWUvIHBhZ2VzIG9yIHRoZSBob3N0IGhhdmUgYSBoZXVyaXN0aWMgdG8gbW9uaXRvcgo+Pj4g dGhlIGd1ZXN0IGFuZCBpbmZsYXRlL2RlZmxhdGUgdGhlIGd1ZXN0IGl0IGlzIGEgbWF0dGVyIG9m IGltcGxlbWVudGF0aW9uLgo+Pgo+PiBQbGVhc2UgZG9uJ3QgYXNzdW1lIHRoYXQgdGhlIHVzZSBj YXNlIGZvciBtZW1vcnkgYmFsbG9vbmluZyBpcyBvbmx5Cj4+IG9wdGltaXppbmcgbWVtb3J5IG92 ZXJjb21taXQgaW4gdGhlIGh5cGVydmlzb3IgdW5kZXIgbWVtb3J5IHByZXNzdXJlLgo+IAo+IEkg dW5kZXJzdG9vZCB0aGF0IC0gY3VycmVudGx5IGl0IGlzIHVzZWQgYW5kIGFzIGEgd2F5IHRvIGRv IAo+IGhvdHBsdWcvdW5wbHVnLiBUaGUgcXVlc3Rpb24gaXMgaWYgdGhhdCBpcyB0aGUgcmlnaHQg d2F5IHRvIHVzZSBpdC4KClBlb3BsZSB1c2UgaXQgbGlrZSB0aGF0LCBhbmQgd2UgaGF2ZSBubyBj b250cm9sIG92ZXIgdGhhdC4gSSd2ZSBoZWFyZCBvZgpwZW9wbGUgdXNpbmcgaG90cGx1ZyBvZiBE SU1NcyB0byBpbmNyZWFzZSBWTSBtZW1vcnkgYW5kIGJhbGxvb24KaW5mbGF0aW9uIHRvIGhvdHVu cGx1ZyBtZW1vcnksIHRvIGRlY3JlYXNlIFZNIG1lbW9yeS4KCj4gCj4+Pgo+Pj4gSG90IHBsdWcg aXMgYWRkaW5nwqAgdG8gTWVtVG90YWwgYW5kIGl0IGlzIG5vdCBhIHJhbmRvbSBldmVudCBlaXRo ZXIgaW4KPj4+IHJlYWwgb3IgdmlydHVhbCBlbnZpcm9ubWVudCAtwqAgc28geW91IGNhbiBhY3Qg dXBvbiBpdC4gTWVtVG90YWzCoCBnb2VzCj4+PiBkb3duIG9uIGhvdCB1bnBsdWcgYW5kIGlmIHBh Z2VzIGdldCBtYXJrZWQgYXMgZmF1bHR5IFJBTS4KPj4KPj4gIm5vdCBhIHJhbmRvbSBldmVudCBl aXRoZXIiIC0tIHN1cmUsIHdpdGggcHBjIGRscGFyLCB4ZW4gYmFsbG9vbiwgaHYKPj4gYmFsbG9v biBvciB2aXJ0aW8tbWVtIC4uLiB3aGljaCBhbGwgYXJlIGFibGUgdG8gaG90cGx1ZyBtZW1vcnkg ZmFpcmx5Cj4+IHJhbmRvbWx5IGJhc2VkIG9uIGh5cGVydmlzb3IgZGVjaXNpb25zLgo+Pgo+PiBJ biBwaHlzaWNhbCBlbnZpcm9ubWVudHMsIGl0J3Mgbm90IHJlYWxseSBhIHJhbmRvbSBldmVudCwg SSBhZ3JlZS4KPiAKPiBFdmVuIGlmIGl0IGlzIG5vdCBtYW51YWwgLSBpZiB0aGV5IGRvIGhvdHBs dWcgaXQgaXMgb2sgLSB5b3UgY2FuIHRyYWNrIAo+IGhvdHBsdWcgZXZlbnRzLiBCdXQgeW91IGNh biBub3QgdHJhY2sgYmFsbG9vbiBldmVudHMuCgpJIHdhcyBhbHJlYWR5IGFza2luZyBteXNlbGYg aW4gdGhlIHBhc3QgaWYgdGhlcmUgc2hvdWxkIGJlIG5vdGlmaWVycwp3aGVuIHdlIGluZmxhdGUv ZGVmbGF0ZSAtLSB3aGVuIHdlIGFkanVzdCBNZW1Ub3RhbCBlc3NlbnRpYWxseS4gQnV0IEkKdGhp bmsgdGhlcmUgaXMgYSBtb3JlIGZ1bmRhbWVudGFsIHByb2JsZW06IHNvbWUgdGhpbmdzIGFyZSBq dXN0CmluY29tcGF0aWJsZSB0byBhbnkgb2YgdGhhdC4KCj4gCj4+Cj4+Pgo+Pj4gSGlzdG9yaWNh bGx5IE1lbVRvdGFsIGlzIGEgc3RhYmxlIHZhbHVlICggaSBhZ3JlZSB3aXRoIG1vc3Qgb2YgRGF2 aWQKPj4+IFN0ZXZlbnMgcG9pbnRzKSBhbmQgdXNlciBzcGFjZSBpcyBleHBlY3RpbmcgaXQgdG8g YmUgc3RhYmxlICwKPj4+IGluaXRpYWxpemVkIGF0IHN0YXJ0dXAgYW5kIGl0IGRvZXMgbm90IGV4 cGVjdCBpdCB0byBjaGFuZ2UuCj4+Cj4+IEp1c3QgbGlrZSBzb21lIGFwcHMgYXJlIG5vdCBwcmVw YXJlZCBmb3IgbWVtb3J5IGhvdCh1bilwbHVnLiBTb21lIGFwcHMKPj4ganVzdCBkb24ndCB3b3Jr IGluIGVudmlyb25tZW50cyB3aXRoIHZhcmlhYmxlIHBoeXNpY2FsIG1lbW9yeSBzaXplczoKPj4g ZXhhbXBsZXMgaW5jbHVkZSBkYXRhYmFzZXMsIHdoZXJlIG1lbW9yeSBiYWxsb29uaW5nIG1pZ2h0 IGVzc2VudGlhbGx5IGJlCj4+IGNvbXBsZXRlbHkgdXNlbGVzcyAodGhlcmUgaXMgYSBwYXBlciBh Ym91dCBhcHBsaWNhdGlvbi1hd2FyZSBtZW1vcnkgPiBiYWxsb29uaW5nIGZvciB0aGF0IGV4YWN0 IHVzZSBjYXNlKS4KPiAKPiBJIHdvdWxkIHNheSB0aGF0IGV2ZW4gdGhlIGtlcm5lbCBpcyBub3Qg cHJlcGFyZWQgdG8gd29yayB3aXRoIGNoYW5naW5nCj4gTWVtVG90YWwgLSB0aGVyZSBhcmUgY2Fj aGVzIHRoYXQgYXJlIHNpemVkIGFjY29yZGluZyB0byBpdCAtCj4gV2hpbGUgd2l0aCBob3RwbHVn IHRoZXJlIGlzIGEgbm90aWZpZXIgYW5kIHdobyBpcyBpbnRlcmVzdGVkIGNhbiB1c2UgaXQuCj4g V2l0aCBiYWxsb29uIGluZmxhdGUvZGVmbGF0ZSB0aGVyZSBpcyBubyB3YXkgdG8gZG8gc28gLCBp bXBsZW1lbnRpbmcKPiBhIGNsb25lIG9mIGhvdHBsdWdfbWVtb3J5X25vdGlmaWVyIGRvZXNuJ3Qg c291bmQgcmlnaHQgZm9yIG1lLgoKQWdhaW4sIGl0IGNvbXBsZXRlbHkgZGVwZW5kcyBvbiB0aGUg dXNlIGNhc2UuCgpBcyBhIHJlZmVyZW5jZSwgd2UgdXNlZCB0byBhZGp1c3QgTWVtVG90YWwgZXZl ciBzaW5jZSB2aXJ0aW8tYmFsbG9vbiB3YXMKaW50cm9kdWNlIGluIHRoZSBrZXJuZWwgKDIwMDMg ISksIHdoaWNoIHdhcyBhbG1vc3QgMjAgKCEpIHllYXJzIGFnby4gSQphbSBub3QgYXdhcmUgb2Yg bWFueSAoYW55KSBjb21wbGFpbnMuIEl0J3MganVzdCB3aGF0IHBlb3BsZSBhY3R1YWxseSBkbwpl eHBlY3QuIENoYW5naW5nIHRoYXQgc3VkZGVubHkgaXMgbm90IG9rLgoKPiAKPiBTYW1lIGZvciB0 aGUgdXNlcnNwYWNlIC0gb24gYSBob3RwbHVnL3VucGx1ZyBldmVudCB5b3UgY2FuIHJlc3RhcnQg eW91ciAKPiBkYXRhYmFzZSBvciBhbnkgb3RoZXIgcHJvY2VzcyBzZW5zaXRpdmUgdG8gdGhlIHZh bHVlIG9mIE1lbVRvdGFsLgoKSU1ITyBkYXRhYmFzZXMgYW5kIGFueSBmb3JtIG9mIE1lbVRvdGFs IGNoYW5nZXMgYXJlIGluY29tYXB0aWJsZSwKYmVjYXVzZSBkYXRhYmFzZXMgYXJlIHNpbXBseSBl eHRyZW1lIG1lbWhvZ3MuCgo+IAo+Pj4KPj4+IFVzZWQgaXMgd2hhdCBjaGFuZ2VzIGFuZCB0aGF0 IGlzIHdoYXQgdXNlciBzcGFjZSBleHBlY3RzIHRvIGNoYW5nZS4KPj4+Cj4+PiBEZWxmYXRlIG9u IG9vbSBtaWdodCBoYXZlIGJlZW4gYSBtaXN0YWtlIGJ1dCBpdCBpcyB0aGVyZSBhbmQgaWYgYW55 dGhpbmcKPj4+IGRlcGVuZHMgb24gY2hhbmdpbmcgTWVtVG90YWzCoCBpdCB3aWxsIGJlIGJyb2tl biBieSB0aGF0IG9wdGlvbi7CoCBIb3cKPj4+IHRoYXQgY2FuIGJlIGZpeGVkPwo+Pgo+PiBJIGRp ZG4ndCBxdWl0ZSBnZXQgeW91ciBjb25jZXJuIGhlcmUuIERlZmxhdGUtb24tb29tIGluIHZpcnRp by1iYWxsb29uID4gd29uJ3QgYWRqdXN0IE1lbVRvdGFsLCBzbyB1bmRlciB3aGljaCBjb25kaXRp b24gd291bGQgYmUgc29tZXRoaW5nIAo+IGJyb2tlbj8KPiAKPiBJIG1lYW4gdGhlIHR3byB3YXlz IG9mIGFjY291bnRpbmcgLSBpZiBhIHByb2Nlc3MgZGVwZW5kcyBvbiBlaXRoZXIKPiB1c2VkIG9y IHRvdGFsIHRvIGNoYW5nZSBpdCB3aWxsIGJyZWFrIGRlcGVuZGluZyBvbiB0aGUgb3B0aW9uIC4K Ci4uLiBhbmQgSSB3b3VsZCBhcmd1ZSB0aGF0IHN1Y2ggYXBwbGljYXRpb25zIGFyZSBub3QgZGVz aWduZWQgZm9yCnBoeXNpY2FsIG1lbW9yeSBjaGFuZ2VzIGluIGFueSBmb3JtLiBBbmQgbm90IGV2 ZW4gZm9yIHJ1bm5pbmcKY29uY3VycmVudGx5IHdpdGggb3RoZXIgYXBwbGljYXRpb25zLgoKWWVz LCB0aGV5IG1pZ2h0IGJlIGNvbXBhdGlibGUgd2l0aCBkZWZsYXRlLW9uLW9vbS4KClsuLi5dCgo+ PiBFeHBvc2luZyBpbmZvcm1hdGlvbiBhYm91dCBpbmZsYXRlZCBwYWdlcyBpbiBhIGdlbmVyaWMg d2F5IGRvZXNuJ3Qgc291bmQKPj4gY29tcGxldGVseSB3cm9uZyB0byBtZSwgYnV0IHRoZXJlIG1p Z2h0IGJlIHBlb3BsZSB0aGF0IG9iamVjdC4KPj4KPiAKPiBQYXRjaCBmb3IgL3Byb2MvbWVtaW5m byBjb21pbmcgbmV4dC4KCkdvb2QhCgo+IAo+Pj4KPj4+Cj4+PiBQbGVhc2UsIHNoYXJlIHlvdXIg dmlldyBvbiBob3cgdGhlIGJhbGxvb25lZCBtZW1vcnkgc2hvdWxkIGJlIGFjY291bnRlZCBieSB0 aGUgZHJpdmVycyBpbnNpZGUgdGhlIGd1ZXN0cyBzbyB3ZSBjYW4gd29yayB0b3dhcmRzIGNvbnNp c3RlbnQgYmVoYXZpb3VyOgo+Pj4KPj4+IFNob3VsZCB0aGUgaW5mbGF0ZWQgbWVtb3J5IGJlIGFj Y291bnRlZCBhcyBVc2VkIG9yIE1lbVRvdGFsIGJlIGFkanVzdGVkPwo+Pgo+PiBJIGhvcGUgSSB3 YXMgYWJsZSB0byBtYWtlIGl0IGNsZWFyIHRoYXQgaXQgY29tcGxldGVseSBkZXBlbmRzIG9uIGhv dwo+PiBtZW1vcnkgYmFsbG9vbmluZyBpcyBhY3R1YWxseSBpbnRlbmRlZCB0byBiZSB1c2VkLiBJ dCdzIG5vdCB1bmNvbW1vbiB0bwo+PiB1c2UgaXQgYXMgZm9ybSBvZiBmYWtlIG1lbW9yeSBob3R1 bnBsdWcsIHdoZXJlIHRoYXQgbWVtb3J5IGlzIGFjdHVhbGx5Cj4+IGdvbmUgZm9yIGdvb2QgYW5k IHdvbid0IHNpbXBseSBjb21lIGJhY2sgd2hlbiB1bmRlciBtZW1vcnkgcHJlc3N1cmUuCj4+Cj4+ Pgo+Pj4gU2hvdWxkIHRoZSBpbmZsYXRlZCBtZW1vcnkgYmUgYWRkZWQgdG8gL3Byb2MvbWVtaW5m byA/Cj4+Cj4+IE15IGd1dCBmZWVsaW5nIGlzIHllcy4gVGhlIGludGVyZXN0aW5nIHF1ZXN0aW9u IHJlbWFpbnMsIGhvdyB0bwo+PiBkaXN0aW5ndWlzaCB0aGUgdHdvIHVzZSBjYXNlcyAoaW5mbGF0 ZWQgbWVtb3J5IHN1YnRyYWN0ZWQgZnJvbSBNZW1Ub3RhbCA+IG9yIHN1YnRyYWN0ZWQgZnJvbSBN ZW1GcmVlKS4KPiAKPiBUaGVyZSBhcmUgY3VycmVudGx5IHR3byBvcHRpb25zOgo+ID09PT09PT09 PT09IFJBTSA9PT09PT09PT09PT09PT09PT09fAo+ICAgICAgICAgIHxfVXNlZCBNYXJrZXIgICAg ICAgICAgICAgIHxfIFRvdGFsIE1hcmtlcgo+IAo+IFlvdSBlaXRoZXIgbW92ZSBVc2VkIG1hcmtl ciBvciBtb3ZlIFRvdGFsIHRvIGFkanVzdC4KPiBGb3Igc2ltcGxpY2l0eSBzaWduIGJpdCBjYW4g YmUgdXNlZC4gSWYgYW4gb3RoZXIgd2F5IGFwcGVhcnMKPiB0aGUgYml0IG5leHQgdG8gdGhlIHNp Z24gYml0IGNhbiBiZSB1c2VkLgo+IAo+Pgo+PiBJJ20gbm90IHN1cmUgaWYgd2UgZXZlbiB3YW50 IHRvIHVuaWZ5IGJhbGxvb24gaGFuZGxpbmcgcmVhZ3JkaW5nCj4+IGFkanVzdGluZyBtYW5hZ2Vk IHBhZ2VzLiBJTUhPLCB0aGVyZSBhcmUgZ29vZCByZWFzb25zIHRvIGRvIGl0IGVpdGhlciB3YXku Cj4gCj4gSSB0aGluayB0aGVyZSBpcyBhIG5lZWQgb2YgY2xlYXIgcnVsZXMgYmFzZWQgb24gd2hh dCBpcyBjb3JyZWN0IGFuZCB3aGF0IAo+IG5vdC4gSXQgc2VlbXMgdGhhdCBjdXJyZW50bHkgZXZl cnkgaHlwZXJ2aXNvci9kcml2ZXIgaXMgZ29pbmcgdGhlIGVhc3kgCj4gd2F5IHdpdGggaG90IHBs dWcvaG90IHVucGx1ZyB2cyBpbmZsYXRlL2RlZmxhdGUgdnMgaG90LWFkZC9ob3QtcmVtb3ZlLgo+ IE5vdyBpZiBpIHRyeSB0byBtYWtlIG15IGFwcCAic21hcnQiIGFib3V0IG1lbW9yeSBwcmVzc3Vy ZSBpIG5lZWQgdG8ga25vdyAKPiB3YXkgdG9vIG11Y2ggYWJvdXQgZWFjaCBjdXJyZW50IGFuZCBm dXR1cmUgaHlwZXJ2aXNvci4KClllYWgsIEkgcmFpc2VkIGluIHRoZSBwYXN0IHRoYXQsIGZvciBl eGFtcGxlIGZvciB2aXJ0aW8tYmFsbG9vbiwgd2UnZApuZWVkIGluZm9ybWF0aW9uIChlLmcuLCBm ZWF0dXJlIGZsYWcpIGZyb20gdGhlIGh5cGVydmlzb3Igd2hhdCBpdCBpcwphY3R1YWxseSBnb2lu ZyB0byBkbzogd2hldGhlciBpdCBpbXBsZW1lbnRzIHNvbWUgZm9ybSBvZiBkZWZsYXRlLW9uLW9v bQpzdWNoIHRoYXQgeW91IGNhbiBhbGxvY2F0ZSBodWdlIHBvcnRpb25zIG9mIG1lbW9yeSBhbmQg aW1tZWRpYXRlbHkgZ2V0CnRoYXQgbWVtb3J5IGZyZWVkIHVwIGluc3RlYWQgb2YgcnVubmluZyBp bnRvIE9PTXMgYW5kIHRyaWdnZXJpbmcKYXBwbGljYXRpb24va2VybmVsIGNyYXNoZXMuCgotLSAK VGhhbmtzLAoKRGF2aWQgLyBkaGlsZGVuYgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18KVmlydHVhbGl6YXRpb24gbWFpbGluZyBsaXN0ClZpcnR1YWxpemF0 aW9uQGxpc3RzLmxpbnV4LWZvdW5kYXRpb24ub3JnCmh0dHBzOi8vbGlzdHMubGludXhmb3VuZGF0 aW9uLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3ZpcnR1YWxpemF0aW9u From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 61B1FC19F2D for ; Tue, 9 Aug 2022 10:03:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240874AbiHIKDw (ORCPT ); Tue, 9 Aug 2022 06:03:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53556 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240472AbiHIKDt (ORCPT ); Tue, 9 Aug 2022 06:03:49 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 255C223BD3 for ; Tue, 9 Aug 2022 03:03:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1660039427; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=z4S7sEwRZF/s5fONnXF+oN53vWEng4sMiupLFnh9W74=; b=ZGbmmIjNl+kpAQtl1sKqsM3mIyGpSojCDOSc1A58LEYZY+Q1tMMLrfg3a27XNRdnUw6vcN Qh3J8KFFBxs7cH0bYi8k+3EjTkEYbg2MqlH+3pMKfMwBkvSszijvJeGKnTDFO59RX0osxL s4uLgx9N3E9LYWwiRIAI6+Kj36odc1U= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-407-4OaEIRT_MriHmwTrAjQhcQ-1; Tue, 09 Aug 2022 06:03:46 -0400 X-MC-Unique: 4OaEIRT_MriHmwTrAjQhcQ-1 Received: by mail-wr1-f71.google.com with SMTP id t12-20020adfa2cc000000b0021e564cde06so1765186wra.17 for ; Tue, 09 Aug 2022 03:03:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:subject:organization:from :references:cc:to:content-language:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc; bh=z4S7sEwRZF/s5fONnXF+oN53vWEng4sMiupLFnh9W74=; b=OBssZeBABtTe9jgG7/W0+KNe9nF4RabHmca2J8Sq4Tsu5hrpnL0MoXPQEFEh44JRbQ +TQ1O5olPfaVK7yFuF8hTC9ptHtFncIPyd9m5rVN+hEL1WaHfDkG2Sb5EDcEbb1z5yVm QRmpYUz6V5t4ZF+9nW9rofOBh9ESN/RJcnHS8KTPFTEmRdvjdmEEg4nh6TPJ8fwWsN1i tYzpSCW1qHJTJv47WxXxLPhL7lifCKvZuANuKUqkmWRrlDlT1JBFa89/m8U32gHFyhMC SDeEleCk6zzuKjtu7iwSVUdZbUOQHzn177w2NpmnyKr8c4AYYpF/BmL/tldJOanh76pR UCSQ== X-Gm-Message-State: ACgBeo2+EgKh4zoVGWXRWDYfd9F7sD4tn26UFBFyjQYh3r84H5s1JA3C 5jfwmiF8z/pzB7oOdJqOueV0IwAZFPPjbDIyU0btIKMFP2nbXm3guBXxQavYmrM8XY5Pgui77SP Lj2Ums2474LewN7GiF7LVoyNI X-Received: by 2002:adf:eb4c:0:b0:220:6aaf:ef5e with SMTP id u12-20020adfeb4c000000b002206aafef5emr13314861wrn.488.1660039424622; Tue, 09 Aug 2022 03:03:44 -0700 (PDT) X-Google-Smtp-Source: AA6agR7y5+8/fEMwrlzoSfhLcMgqH5R7lIz5Q92iaf/1I0YI3oGEeG6j/+HbyhSs4Xw/986oaQT4yA== X-Received: by 2002:adf:eb4c:0:b0:220:6aaf:ef5e with SMTP id u12-20020adfeb4c000000b002206aafef5emr13314830wrn.488.1660039424232; Tue, 09 Aug 2022 03:03:44 -0700 (PDT) Received: from ?IPV6:2003:d8:2f15:c300:d2ce:1fb5:2460:179a? (p200300d82f15c300d2ce1fb52460179a.dip0.t-ipconnect.de. [2003:d8:2f15:c300:d2ce:1fb5:2460:179a]) by smtp.gmail.com with ESMTPSA id o24-20020a05600c511800b003a54f49c1c8sm3730714wms.12.2022.08.09.03.03.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 09 Aug 2022 03:03:43 -0700 (PDT) Message-ID: Date: Tue, 9 Aug 2022 12:03:42 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Content-Language: en-US To: Alexander Atanasov , "Michael S. Tsirkin" , Jason Wang Cc: kernel@openvz.org, virtualization@lists.linux-foundation.org, linux-kernel@vger.kernel.org, stevensd@chromium.org, Boris Ostrovsky , Juergen Gross , Stefano Stabellini , Wei Liu , Stephen Hemminger , Haiyang Zhang , "K. Y. Srinivasan" , Nadav Amit , Arnd Bergmann , Greg Kroah-Hartman , Andrew Morton , Johannes Weiner References: <55016ed9-7b3c-c4eb-f5f4-02cfce2191e4@redhat.com> <20220726140831.72816-1-alexander.atanasov@virtuozzo.com> <2d0703da-ae89-7002-f500-300a4b5d206b@redhat.com> <3a5e60e8-a0d2-a1f1-28e9-e0b45069029a@virtuozzo.com> <71e73194-1683-b65f-7b84-c0c719010aef@redhat.com> <2dfad5c8-59d2-69a1-cc4c-d530c12ceea9@virtuozzo.com> <7bfac48d-2e50-641b-6523-662ea4df0240@virtuozzo.com> From: David Hildenbrand Organization: Red Hat Subject: Re: [RFC] how the ballooned memory should be accounted by the drivers inside the guests? (was:[PATCH v6 1/2] Create debugfs file with virtio balloon usage information) In-Reply-To: <7bfac48d-2e50-641b-6523-662ea4df0240@virtuozzo.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09.08.22 11:36, Alexander Atanasov wrote: > Hello, > > On 2.08.22 16:48, David Hildenbrand wrote: >>>> >>>> In case of Hyper-V I remember a customer BUG report that requested that >>>> exact behavior, however, I'm not able to locate the BZ quickly. >>>> [1] https://lists.linuxfoundation.org/pipermail/virtualization/2021-November/057767.html >>>> (note that I can't easily find the original mail in the archives) >>> >>> VMWare does not, Xen do, HV do (but it didn't) - Virtio does both. >>> >>> For me the confusion comes from mixing ballooning and hot plug. >> >> For example, QEMU (and even libvirt) doesn't even have built in support >> for any kind of automatic balloon resizing on guest memory pressure (and >> I'm happy that we don't implement any such heuristics). As a user/admin, >> all you can do is manually adjust the logical VM size by requesting to >> inflate/deflate the balloon. For virtio-balloon, we cannot derive what >> the hypervisor/admin might or might not do -- and whether the admin >> intends to use memory ballooning for memory hotunplug or for optimizing > memory overcommit. > > Is the lack of proper hotplug/unplug leading the admins to use it like > this? Yes. Especially unplug is tricky and hard to get working reliably in practice because of unmovable pages. Ballooning is an easy hack to get unplug somewhat working. For reference: under Windows ballooning was (and maybe still mostly is) the only way to unplug memory again. Unplug of DIMMs is not supported. > I really don't understand why you don't like automatic resizing - > both HyperV and VMWare do it ? You need heuristics to guess what the guest might be doing next and deflate fast enough to avoid any kind of OOMs in the guest. I pretty much dislike that concept, because it just screams to be fragile. In short: I don't like ballooning, to me it's a technology from ancient times before we were able to do any better. In comparison, I do like free page reporting for optimizing memory overcommit, but it still has some drawbacks (caches consuming too much memory), that people are working on to improve. So we're stuck with ballooning for now for some use cases. Personally, I consider any balloon extensions (inflate/deflate, not things like free page reporting) a waste of time and effort, but that's just my humble opinion. So I keep reviewing and maintaining them ;) > >> As another example, HV dynamic memory actually combines memory hotplug >> with memory ballooning: use memory hotplug to add more memory on demand >> and use memory ballooning to logically unplug memory again. > > Have both as an options - min/max memory , percentage free to keep as > minimum, fixed size and have hot add - kind of hot plug to go above > initial max - tries to manage it in dynamic way. > >> The VMWare balloon is a bit special, because it actually usually >> implements deflate-on-oom semantics in the hypervisor. IIRC, the >> hypervisor will actually adjust the balloon size based on guest memory >> stats, and there isn't really an interface to manually set the balloon >> size for an admin. But I might be wrong regarding the latter. > > For me this is what makes sense - you have a limited amount of > physical RAM that you want to be used optimally by the guests. > Waiting for the admin to adjust the balloon would not give very > optimal results. Exactly. For the use case of optimizing memory overcommit in the hypervisor, you want deflate-on-oom semantics if you go with balloon inflation/deflation. > >> >>> >>> Ballooning is like a heap inside the guest from which the host can >>> allocate/deallocate pages, if there is a mechanism for the guest to ask >>> the host for more/to free/ pages or the host have a heuristic to monitor >>> the guest and inflate/deflate the guest it is a matter of implementation. >> >> Please don't assume that the use case for memory ballooning is only >> optimizing memory overcommit in the hypervisor under memory pressure. > > I understood that - currently it is used and as a way to do > hotplug/unplug. The question is if that is the right way to use it. People use it like that, and we have no control over that. I've heard of people using hotplug of DIMMs to increase VM memory and balloon inflation to hotunplug memory, to decrease VM memory. > >>> >>> Hot plug is adding  to MemTotal and it is not a random event either in >>> real or virtual environment -  so you can act upon it. MemTotal  goes >>> down on hot unplug and if pages get marked as faulty RAM. >> >> "not a random event either" -- sure, with ppc dlpar, xen balloon, hv >> balloon or virtio-mem ... which all are able to hotplug memory fairly >> randomly based on hypervisor decisions. >> >> In physical environments, it's not really a random event, I agree. > > Even if it is not manual - if they do hotplug it is ok - you can track > hotplug events. But you can not track balloon events. I was already asking myself in the past if there should be notifiers when we inflate/deflate -- when we adjust MemTotal essentially. But I think there is a more fundamental problem: some things are just incompatible to any of that. > >> >>> >>> Historically MemTotal is a stable value ( i agree with most of David >>> Stevens points) and user space is expecting it to be stable , >>> initialized at startup and it does not expect it to change. >> >> Just like some apps are not prepared for memory hot(un)plug. Some apps >> just don't work in environments with variable physical memory sizes: >> examples include databases, where memory ballooning might essentially be >> completely useless (there is a paper about application-aware memory > ballooning for that exact use case). > > I would say that even the kernel is not prepared to work with changing > MemTotal - there are caches that are sized according to it - > While with hotplug there is a notifier and who is interested can use it. > With balloon inflate/deflate there is no way to do so , implementing > a clone of hotplug_memory_notifier doesn't sound right for me. Again, it completely depends on the use case. As a reference, we used to adjust MemTotal ever since virtio-balloon was introduce in the kernel (2003 !), which was almost 20 (!) years ago. I am not aware of many (any) complains. It's just what people actually do expect. Changing that suddenly is not ok. > > Same for the userspace - on a hotplug/unplug event you can restart your > database or any other process sensitive to the value of MemTotal. IMHO databases and any form of MemTotal changes are incomaptible, because databases are simply extreme memhogs. > >>> >>> Used is what changes and that is what user space expects to change. >>> >>> Delfate on oom might have been a mistake but it is there and if anything >>> depends on changing MemTotal  it will be broken by that option.  How >>> that can be fixed? >> >> I didn't quite get your concern here. Deflate-on-oom in virtio-balloon > won't adjust MemTotal, so under which condition would be something > broken? > > I mean the two ways of accounting - if a process depends on either > used or total to change it will break depending on the option . ... and I would argue that such applications are not designed for physical memory changes in any form. And not even for running concurrently with other applications. Yes, they might be compatible with deflate-on-oom. [...] >> Exposing information about inflated pages in a generic way doesn't sound >> completely wrong to me, but there might be people that object. >> > > Patch for /proc/meminfo coming next. Good! > >>> >>> >>> Please, share your view on how the ballooned memory should be accounted by the drivers inside the guests so we can work towards consistent behaviour: >>> >>> Should the inflated memory be accounted as Used or MemTotal be adjusted? >> >> I hope I was able to make it clear that it completely depends on how >> memory ballooning is actually intended to be used. It's not uncommon to >> use it as form of fake memory hotunplug, where that memory is actually >> gone for good and won't simply come back when under memory pressure. >> >>> >>> Should the inflated memory be added to /proc/meminfo ? >> >> My gut feeling is yes. The interesting question remains, how to >> distinguish the two use cases (inflated memory subtracted from MemTotal > or subtracted from MemFree). > > There are currently two options: > =========== RAM ===================| > |_Used Marker |_ Total Marker > > You either move Used marker or move Total to adjust. > For simplicity sign bit can be used. If an other way appears > the bit next to the sign bit can be used. > >> >> I'm not sure if we even want to unify balloon handling reagrding >> adjusting managed pages. IMHO, there are good reasons to do it either way. > > I think there is a need of clear rules based on what is correct and what > not. It seems that currently every hypervisor/driver is going the easy > way with hot plug/hot unplug vs inflate/deflate vs hot-add/hot-remove. > Now if i try to make my app "smart" about memory pressure i need to know > way too much about each current and future hypervisor. Yeah, I raised in the past that, for example for virtio-balloon, we'd need information (e.g., feature flag) from the hypervisor what it is actually going to do: whether it implements some form of deflate-on-oom such that you can allocate huge portions of memory and immediately get that memory freed up instead of running into OOMs and triggering application/kernel crashes. -- Thanks, David / dhildenb