[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <88EDC41D-408F-4ADF-A933-0A6F36E5F262@gmail.com>
Date: Wed, 5 Oct 2022 10:25:47 -0700
From: Nadav Amit <nadav.amit@...il.com>
To: Alexander Atanasov <alexander.atanasov@...tuozzo.com>
Cc: "Michael S. Tsirkin" <mst@...hat.com>,
David Hildenbrand <david@...hat.com>,
Andrew Morton <akpm@...ux-foundation.org>, kernel@...nvz.org,
Linux Virtualization <virtualization@...ts.linux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>, linux-mm@...ck.org
Subject: Re: [PATCH v4 2/7] Enable balloon drivers to report inflated memory
On Oct 5, 2022, at 2:01 AM, Alexander Atanasov <alexander.atanasov@...tuozzo.com> wrote:
> Add counters to be updated by the balloon drivers.
> Create balloon notifier to propagate changes.
I missed the other patches before (including this one). Sorry, but next
time, please cc me.
I was looking through the series and I did not see actual users of the
notifier. Usually, it is not great to build an API without users.
[snip]
> +
> +static int balloon_notify(unsigned long val)
> +{
> + return srcu_notifier_call_chain(&balloon_chain, val, NULL);
Since you know the inflated_kb value here, why not to use it as an argument
to the callback? I think casting to (void *) and back is best. But you can
also provide pointer to the value. Doesn’t it sound better than having
potentially different notifiers reading different values?
Anyhow, without users (actual notifiers) it’s kind of hard to know how
reasonable it all is. For instance, is it balloon_notify() supposed to
prevent further balloon inflating/deflating until the notifier completes?
Accordingly, are callers to balloon_notify() expected to relinquish locks
before calling balloon_notify() to prevent deadlocks and high latency?
Powered by blists - more mailing lists