On Wed, Jun 09, 2021 at 10:23:36PM +0800, yong w wrote:

Greg KH [off-list ref] 于2021年6月8日周二 下午5:29写道：

quoted

On Mon, Jun 07, 2021 at 08:39:14AM -0700, yongw.pur@gmail.com wrote:

quoted

From: wangyong <redacted>

When zram is used, available+Swap free memory is obviously bigger than we
actually can use, because zram can compress memory by compression
algorithm and zram compressed data will occupy memory too.

So, we can count the compression ratio of zram in the kernel. The space
will be saved by zram and other swap device are calculated as follows:
zram[swapfree - swapfree * compress ratio] + swapdev[swapfree]
We can evaluate the available memory of the whole system as:
MemAvailable+zram[swapfree - swapfree * compress ratio]+swapdev[swapfree]

Why is this needed to be exported by userspace?  Who is going to use
this information and why can't they just calculate it from the exported
information already?

In embedded devices, it is necessary to assess how much memory is available.

Why is that any different from a server?  Or a laptop?  Or any other
system running Linux?  "embedded" isn't special here :)

If the memory allocation is based on available+swapfree, it may cause oom and
affect the normal use of the devices. And it is more accurate and safe
to calculate
the swap available memory through minimum compression ratio.

Although mm_stat interface provides compressed information，but it is not easy to
get the minimum compression ratio during swaping out. Kernel provides a common
interface, which makes it easier to use and judge the state of system memory

If you are running up against this type of limit, how is a proc file
guess going to help much?  What are you going to do based on the result?
And as it's always going to be a guess, how reliable is it?

quoted

What tool requires this new information and what is it going to be used
for?

It can be used in embedded devices to evaluate the memory condition
and avoid causing oom; Also If we wants to know more accurate available
memory information when zram is used.

Why not rely on the oom logic instead?  What is wrong with that as this
is always going to be just a guess.  You are never going to be able to
react fast enough to reading this value to be able to do anything better
than you could through the existing oom notifier/logic, right?

quoted

And why add a block driver's information to a core proc file?  Shouldn't
the information only be in the block driver's sysfs directory only?

thanks,

greg k-h

I thought it would be better to put it there.

If no one needs it, why add it?  :)

In the first patch, MemAvailable returned with swap available memory, and
David recommended a separate interface.

A sysfs file makes more sense to me, and seems simpler.

But again, this is just a guess, trying to do real work based on it
feels really risky.

thanks,

greg k-h