Re: [RFC PATCH V3] zram:calculate available memory when zram is used

From: Greg KH <gregkh@linuxfoundation.org>
To: yong w <yongw.pur@gmail.com>
Cc: minchan@kernel.org, ngupta@vflare.org, senozhatsky@chromium.org,
	axboe@kernel.dk, akpm@linux-foundation.org,
	songmuchun@bytedance.com, David Hildenbrand <david@redhat.com>,
	linux-kernel@vger.kernel.org, linux-block@vger.kernel.org,
	linux-mm@kvack.org, willy@infradead.org,
	linux-api@vger.kernel.org, lu.zhongjun@zte.com.cn,
	yang.yang29@zte.com.cn, zhang.wenya1@zte.com.cn,
	wang.yong12@zte.com.cn
Subject: Re: [RFC PATCH V3] zram:calculate available memory when zram is used
Date: Wed, 9 Jun 2021 16:59:58 +0200	[thread overview]
Message-ID: <YMDXbh0H20MPG87V@kroah.com> (raw)
In-Reply-To: <CAOH5QeBV5zq=SpMSxZHJqgmfKegdgc7ehpots6AKjjgEYq5rGg@mail.gmail.com>

On Wed, Jun 09, 2021 at 10:23:36PM +0800, yong w wrote:
> Greg KH <gregkh@linuxfoundation.org> 于2021年6月8日周二 下午5:29写道：
> 
> >
> > On Mon, Jun 07, 2021 at 08:39:14AM -0700, yongw.pur@gmail.com wrote:
> > > From: wangyong <wang.yong12@zte.com.cn>
> > >
> > > 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?

> > 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?

> > 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