Re: [PATCH v1 1/2] Enable balloon drivers to report inflated memory

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 9.08.22 13:32, Michael S. Tsirkin wrote:
On Tue, Aug 09, 2022 at 12:49:32PM +0300, Alexander Atanasov wrote:
@@ -153,6 +156,14 @@ static int meminfo_proc_show(struct seq_file *m, void *v)
  		    global_zone_page_state(NR_FREE_CMA_PAGES));
  #endif
+#ifdef CONFIG_MEMORY_BALLOON
+	inflated_kb = atomic_long_read(&mem_balloon_inflated_kb);
+	if (inflated_kb >= 0)
+		seq_printf(m,  "Inflated(total): %8ld kB\n", inflated_kb);
+	else
+		seq_printf(m,  "Inflated(free): %8ld kB\n", -inflated_kb);
+#endif
+
  	hugetlb_report_meminfo(m);
arch_report_meminfo(m);


This seems too baroque for my taste.
Why not just have two counters for the two pruposes?

I agree it is not good but it reflects the current situation.
Dirvers account in only one way - either used or total - which i don't like. So to save space and to avoid the possibility that some driver starts to use both at the same time. I suggest to be only one value.


And is there any value in having this atomic?
We want a consistent value but just READ_ONCE seems sufficient ...

I do not see this as only a value that is going to be displayed.
I tried to be defensive here and to avoid premature optimization.
One possible scenario is OOM killer(using the value) vs balloon deflate on oom will need it. But any other user of that value will likely need it atomic too. Drivers use spin_locks for calculations they might find a way to reduce the spin lock usage and use the atomic.
While making it a long could only bring bugs without benefits.
It is not on a fast path too so i prefer to be safe.

--
Regards,
Alexander Atanasov





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux