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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8A6F4C433FE for ; Fri, 14 Oct 2022 13:03:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E87356B0072; Fri, 14 Oct 2022 09:03:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E10FD6B0075; Fri, 14 Oct 2022 09:03:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C3BB96B0078; Fri, 14 Oct 2022 09:03:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id AAA496B0072 for ; Fri, 14 Oct 2022 09:03:10 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 2574380840 for ; Fri, 14 Oct 2022 13:03:10 +0000 (UTC) X-FDA: 80019570540.07.A8A2CBA Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf05.hostedemail.com (Postfix) with ESMTP id 6B9CC100044 for ; Fri, 14 Oct 2022 13:01:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1665752473; 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=SaldHj1fWL0JB8uDShPZGUz9Hou91o0Rg4EAQ11LSaw=; b=gJDgn0OqF0/I9/ibpHSHmJLiL6bnnR4s8yU3HAZ3cPocchRukfIOzMnkt1ZJ94F2AhEa8z TMUpsOAhAKOnXfWZ2JMtihxrtdn1ZnB8K1tiz4HbvV1esbTH9IIx7QS/CyJxafJ+o8DIsi TS7cEKXpCvLClidg5cxTBwGtC8DGKbQ= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-634-zY-7rnbBMHe70k3JVRvr9Q-1; Fri, 14 Oct 2022 09:01:12 -0400 X-MC-Unique: zY-7rnbBMHe70k3JVRvr9Q-1 Received: by mail-wm1-f70.google.com with SMTP id c3-20020a7bc843000000b003b486fc6a40so2146936wml.7 for ; Fri, 14 Oct 2022 06:01:11 -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:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=SaldHj1fWL0JB8uDShPZGUz9Hou91o0Rg4EAQ11LSaw=; b=pYr9qcszSiPiAXtbMrClFkFRxp+iXSP0lUhmR4v1QbrhCtlIqlUi6eC3P5CNsNZk0K E37ldrT5WqMbN8szV1v1/dme5hu7uUB31Ir0uZBahmW2EJOcp+rcPz7+TL4xoRasirsM 7qa8dQNC3DFePxXvW8CkPEig6mP7BYOoSdJ+QtU8HrH3C0d2T58Th5jBDEUWEolmuZ8Q p6tckw8huSwx1buC39UOkPXUgT7bztMc/tZAuoOEr6D0Rgmr0/eLSi4K9CxcKXqnc1Fd ciSS6v6/jH4aNY5SeycwjIQKJfP6x5yst/6geuJfOUdiuF5XEy0WvyhJXyJe62P9Of18 DaCw== X-Gm-Message-State: ACrzQf3mYOZCr5+yDCOlAtahUUn/n/oA7Jjx4Tbui4POD+rbt+o5DlJb P20RxHMGbRGLLXzR3xXXWndWIloNY2pz1wsyAK0eROrKs72NWplOG/K5QrkYuwi3A47s01Y5jmn 8kdafw+j18+o= X-Received: by 2002:a5d:47c5:0:b0:22e:6941:81eb with SMTP id o5-20020a5d47c5000000b0022e694181ebmr3293004wrc.408.1665752470730; Fri, 14 Oct 2022 06:01:10 -0700 (PDT) X-Google-Smtp-Source: AMsMyM64LAt/bXBlG7HpFfz2D7sSRGhelA92JwzG3QdzpfXGbbOKe2ptF7MkqUTL6DhtBxrsuST3Eg== X-Received: by 2002:a5d:47c5:0:b0:22e:6941:81eb with SMTP id o5-20020a5d47c5000000b0022e694181ebmr3292947wrc.408.1665752470102; Fri, 14 Oct 2022 06:01:10 -0700 (PDT) Received: from ?IPV6:2003:cb:c704:8f00:9219:ab4c:826e:9646? (p200300cbc7048f009219ab4c826e9646.dip0.t-ipconnect.de. [2003:cb:c704:8f00:9219:ab4c:826e:9646]) by smtp.gmail.com with ESMTPSA id l15-20020a05600c4f0f00b003c6cc57566fsm6123016wmq.14.2022.10.14.06.01.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 14 Oct 2022 06:01:09 -0700 (PDT) Message-ID: <72e535ce-80eb-a02f-970c-6a9c80da0a24@redhat.com> Date: Fri, 14 Oct 2022 15:01:08 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.1 Subject: Re: RFC [PATCH v4 2/7] Enable balloon drivers to report inflated memory To: Alexander Atanasov , Nadav Amit Cc: "Michael S. Tsirkin" , Andrew Morton , kernel@openvz.org, Linux Virtualization , LKML , Linux MM References: <20221005090158.2801592-1-alexander.atanasov@virtuozzo.com> <20221005090158.2801592-3-alexander.atanasov@virtuozzo.com> <88EDC41D-408F-4ADF-A933-0A6F36E5F262@gmail.com> <42C75E59-696B-41D5-BD77-68EFF0B075C6@gmail.com> <71E14334-CA3B-45FB-A854-7A8D6649C798@gmail.com> <1118F098-972A-4F58-8EE1-270A06E4F9D1@gmail.com> <7ba328e5-3bc8-cb22-f00c-eddb8aea9a06@virtuozzo.com> <063efd58-8373-90ea-7c5e-9d0e9161d2ba@redhat.com> <04e5a2e4-052d-0f80-d642-4e104307f38b@virtuozzo.com> From: David Hildenbrand Organization: Red Hat In-Reply-To: <04e5a2e4-052d-0f80-d642-4e104307f38b@virtuozzo.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1665752474; h=from:from:sender: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:dkim-signature; bh=SaldHj1fWL0JB8uDShPZGUz9Hou91o0Rg4EAQ11LSaw=; b=sdNfGVw1hwh2B4GL7MLG/HlmbCFhRjc8imEK1zdsP25vdMkIjtfI420FlM5OEOX8/mol/X +WnwHZ3/UZwaxYENy9VZ+IUYCJbLJlyWDe+mQU/WZmzSBvkX1KBkadPOzDaSBRsDTuM60M sFWwOK1qco3mtGE8kYRXnavF3DYFqAw= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=gJDgn0Oq; spf=pass (imf05.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1665752474; a=rsa-sha256; cv=none; b=Z7jXq+BhwhO/MZ03FSFSIX24mHT6TQMDz0PM8ujBm4gtcFA2WMR6cJE7sHg8u3OW3fW6f0 qx7R1mHNc9OO8ahtEO8nXkTo5jbCRgCz2aTatxNDLkffRjn7XOTqAMVvqsgSfgJcsgBd7K ysiMPbyfUAzGts0zK4L9vLINB3gIGrY= X-Rspam-User: X-Rspamd-Queue-Id: 6B9CC100044 X-Stat-Signature: atchkqij9bzik7maokdpahih4n1h7yzt Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=gJDgn0Oq; spf=pass (imf05.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Rspamd-Server: rspam10 X-HE-Tag: 1665752474-545198 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 14.10.22 14:50, Alexander Atanasov wrote: > Hello, > > On 11.10.22 12:23, David Hildenbrand wrote: >>>>>> Sounds to me that all you want is some notifier to be called from >>>>>> adjust_managed_page_count(). What am I missing? >>>>> >>>>> Notifier will act as an accumulator to report size of change and it >>>>> will make things easier for the drivers and users wrt locking. >>>>> Notifier is similar to the memory hotplug notifier. >>>> >>>> Overall, I am not convinced that there is any value of separating the >>>> value >>>> and the notifier. You can batch both or not batch both. In addition, >>>> as I >>>> mentioned, having two values seems racy. >>> >>> I have identified two users so far above - may be more to come. >>> One type needs the value to adjust. Also having the value is necessary >>> to report it to users and oom. There are options with callbacks and so >>> on but it will complicate things with no real gain. You are right about >>> the atomicity but i guess if that's a problem for some user it could >>> find a way to ensure it. i am yet to find such place. >>> >> >> I haven't followed the whole discussion, but I just wanted to raise that >> having a generic mechanism to notify on such changes could be valuable. >> >> For example, virtio-mem also uses adjust_managed_page_count() and might >> sometimes not trigger memory hotplug notifiers when adding more memory >> (essentially, when it fake-adds memory part of an already added Linux >> memory block). >> >> What might make sense is schedule some kind of deferred notification on >> adjust_managed_page_count() changes. This way, we could notify without >> caring about locking and would naturally batch notifications. >> >> adjust_managed_page_count() users would not require changes. > > Making it deferred will bring issues for both the users of the > adjust_managed_page_count and the receivers of the notification - > locking as first. And it is hard to know when the adjustment will > finish, some of the drivers wait and retry in blocks. It will bring > complexity and it will not be possible to convert users in small steps. What exactly is the issue about handling that deferred? Who needs an immediate, 100% precise notification? Locking from a separate workqueue shouldn't be too hard, or what am i missing? > > Other problem is that there are drivers that do not use > adjust_managed_page_count(). Which ones? Do we care? -- Thanks, David / dhildenb