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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2B71EC433EF for ; Tue, 15 Mar 2022 17:44:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AE8448D0003; Tue, 15 Mar 2022 13:44:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A96BB8D0001; Tue, 15 Mar 2022 13:44:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 95FC48D0003; Tue, 15 Mar 2022 13:44:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0131.hostedemail.com [216.40.44.131]) by kanga.kvack.org (Postfix) with ESMTP id 8825F8D0001 for ; Tue, 15 Mar 2022 13:44:54 -0400 (EDT) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 39DFD182057E9 for ; Tue, 15 Mar 2022 17:44:54 +0000 (UTC) X-FDA: 79247346108.21.16EA69C Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf30.hostedemail.com (Postfix) with ESMTP id 6888A8000F for ; Tue, 15 Mar 2022 17:44:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=+TV4u+fka6NmbVTg8AiuGEnj8KksGrxh2QycKle+auE=; b=mU8BsnmCdFVS0xbV8+QIe5FBhG xnk/PFuUpA6SmByVnVwctQI5JM+09DS6kRPtaE64zXhePkamEy07A5wY/dDDddTUDaZAwsmf0xqrA HLoQt9pzKNHLcNZy3RQ23DY3z1QLlSb1T8bXsXw5BISSL9e5Er0qlCDeILYFfMjqqNZbPiOnsD+TU AdEai8gGPXocgfYC4z7MgsMkJMPQ/EthBZ6Ny9NUmDswqWkP1se19PjnZ/n8kBDd0MGntpVhICZ5W n4A7D8RGbs3vGpkepFccxf0NNDSww8RMVYpl+QLxxrzFS7z/BIyVhdtLWzEKLnts7iqI/Veo4GHMq ZqcBdv/Q==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1nUBDz-005FDw-Ut; Tue, 15 Mar 2022 17:44:47 +0000 Date: Tue, 15 Mar 2022 17:44:47 +0000 From: Matthew Wilcox To: Brian Geffon Cc: Andrew Morton , Minchan Kim , Nitin Gupta , Sergey Senozhatsky , LKML , linux-doc@vger.kernel.org, linux-block@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH] zram: Add a huge_idle writeback mode Message-ID: References: <20220315172221.9522-1-bgeffon@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 6888A8000F X-Stat-Signature: e8pk6jceipskztz7aat6hi13kmcwt7cm Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=mU8BsnmC; dmarc=none; spf=none (imf30.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org X-HE-Tag: 1647366293-271257 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 Tue, Mar 15, 2022 at 01:34:21PM -0400, Brian Geffon wrote: > On Tue, Mar 15, 2022 at 1:28 PM Matthew Wilcox wrote: > > > > On Tue, Mar 15, 2022 at 10:22:21AM -0700, Brian Geffon wrote: > > > Today it's only possible to write back as a page, idle, or huge. > > > A user might want to writeback pages which are huge and idle first > > > as these idle pages do not require decompression and make a good > > > first pass for writeback. > > > > We're moving towards having many different sizes of page in play, > > not just PMD and PTE sizes. Is this patch actually a good idea in > > a case where we have, eg, a 32kB anonymous page on a system with 4kB > > pages? How should zram handle this case? What's our cut-off for > > declaring a page to be "huge"? > > > > Huge isn't a great term IMO, but it is what it is. ZRAM_HUGE is used > to identify pages which are incompressible. Since zram is a block > device which presents PAGE_SIZED blocks, do these new changes which > involve many different page sizes matter as that seems orthogonal to > the block subsystem. Correct me if I'm misunderstanding. Oh, so ZRAM's concept of huge is not the same as the "huge" in "hugetlbfs" or "THP"? That's not at all confusing ...