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