From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 59869C48BCD for ; Wed, 9 Jun 2021 15:00:04 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id EB544613B9 for ; Wed, 9 Jun 2021 15:00:03 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EB544613B9 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linuxfoundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 7F28F6B006C; Wed, 9 Jun 2021 11:00:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7C89E6B0070; Wed, 9 Jun 2021 11:00:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6917F6B0071; Wed, 9 Jun 2021 11:00:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0233.hostedemail.com [216.40.44.233]) by kanga.kvack.org (Postfix) with ESMTP id 368366B006C for ; Wed, 9 Jun 2021 11:00:03 -0400 (EDT) Received: from smtpin40.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id B6E658249980 for ; Wed, 9 Jun 2021 15:00:02 +0000 (UTC) X-FDA: 78234495444.40.F7EF9D5 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf21.hostedemail.com (Postfix) with ESMTP id 51D82E000279 for ; Wed, 9 Jun 2021 14:59:56 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 46166611CC; Wed, 9 Jun 2021 15:00:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1623250800; bh=49nXecvhsLBHihPFzr4F1shvMNvWEV2skUmEodggHXs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=N7/Nd/zuds8aJM/XE8CD7Qy708zqWC+oTwV5MoOmEHCPALfB37ouXaY5eSmS4j4eO HNjLgTrAPIM5H3TRpZQQQpErtoQZAjEhuly03r7j3mv0Vv2sbCrJN1Bc0IivMIxPrg zlugSh2FzNlpApkjnRjS3w7t+Mv+Nz7VUM2t1/oQ= Date: Wed, 9 Jun 2021 16:59:58 +0200 From: Greg KH To: yong w Cc: minchan@kernel.org, ngupta@vflare.org, senozhatsky@chromium.org, axboe@kernel.dk, akpm@linux-foundation.org, songmuchun@bytedance.com, David Hildenbrand , 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 Message-ID: References: <1623080354-21453-1-git-send-email-yongw.pur@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=linuxfoundation.org header.s=korg header.b="N7/Nd/zu"; dmarc=pass (policy=none) header.from=linuxfoundation.org; spf=pass (imf21.hostedemail.com: domain of gregkh@linuxfoundation.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=gregkh@linuxfoundation.org X-Rspamd-Server: rspam02 X-Stat-Signature: rkaw8crhz4xyeucni8h6wd7r4qihsmno X-Rspamd-Queue-Id: 51D82E000279 X-HE-Tag: 1623250796-311444 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Jun 09, 2021 at 10:23:36PM +0800, yong w wrote: > Greg KH =E4=BA=8E2021=E5=B9=B46=E6=9C=888=E6= =97=A5=E5=91=A8=E4=BA=8C =E4=B8=8B=E5=8D=885:29=E5=86=99=E9=81=93=EF=BC=9A >=20 > > > > On Mon, Jun 07, 2021 at 08:39:14AM -0700, yongw.pur@gmail.com wrote: > > > From: wangyong > > > > > > When zram is used, available+Swap free memory is obviously bigger t= han 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 s= pace > > > will be saved by zram and other swap device are calculated as follo= ws: > > > 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[swa= pfree] > > > > 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 export= ed > > information already? >=20 > In embedded devices, it is necessary to assess how much memory is avail= able. 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 o= om 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. >=20 > Although mm_stat interface provides compressed information=EF=BC=8Cbut = 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 m= emory 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 us= ed > > for? >=20 > 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? Should= n't > > the information only be in the block driver's sysfs directory only? > > > > thanks, > > > > greg k-h >=20 > 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, a= nd > 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