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 141FCECAAA1 for ; Mon, 12 Sep 2022 06:07:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6F6D48D0002; Mon, 12 Sep 2022 02:07:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 67F6A8D0001; Mon, 12 Sep 2022 02:07:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5200A8D0002; Mon, 12 Sep 2022 02:07:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 3CB328D0001 for ; Mon, 12 Sep 2022 02:07:56 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 17B8040135 for ; Mon, 12 Sep 2022 06:07:56 +0000 (UTC) X-FDA: 79902402552.08.7ECEAFD Received: from mail-pf1-f181.google.com (mail-pf1-f181.google.com [209.85.210.181]) by imf04.hostedemail.com (Postfix) with ESMTP id BCA014008F for ; Mon, 12 Sep 2022 06:07:55 +0000 (UTC) Received: by mail-pf1-f181.google.com with SMTP id e5so7625696pfl.2 for ; Sun, 11 Sep 2022 23:07:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date; bh=heRnSh/ihPz3+Q+MxSXEW9Y8QcvUAW165V+3AmdWDkE=; b=IotzQhJcjicWgQP5XMB/92HGjGlouQVWh7eoE8Bej5xDodZfchNwMswgQ/VZjg+bNJ flPZn0Rjbs+CeV65AWIVvLp9lpWJb214z/YM8hZXah9l9E9/CeeEDlJQAjY8ULRQfGKf smbZt0e13eKDmTLcO/8lTk2ZzyKc93hD3mqRE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date; bh=heRnSh/ihPz3+Q+MxSXEW9Y8QcvUAW165V+3AmdWDkE=; b=cLNhdhJgI+107BBTFSzkTbqSRPgjQd8CZpzI09UPgiVJ30kmMyAcjAq1F8I1T/aODr aWl8YnrFAwaXqhC4dg3wDoI4cq7vnNi16jr7LwbSNRZs7OgrNr5+Qtla/6WZ7flescmi FUrt5/eg+LdL9E1wm1K0FF6aubJlcCfaUMNgVDd+FTiLNw6m4PG2gbxAEQzPt7puvQS5 V0yuP4fyLLa0FSmFuvdKE8Grvm8ty0p6tKzOXV0U02IsIZrlmB4t8aIccZ6vgmvxkFK+ rVk2MKghMDthsjSmfk6RLd7I/InXdKrjZa5Foybd7lEXZK2+xNm3YMq8JxM68J8hC0uY XMWg== X-Gm-Message-State: ACgBeo3YMXPyziZtmEbg1AzYyvKyoISQp6KusyVQSmSvfuQXQCYFTAyy fAOyMIGxjTETB56pzIVJItkZVg== X-Google-Smtp-Source: AA6agR4QuFyNN1qZkl+zW7LinZvUDCkJQmpMsBN8qqIqAmQeTFDLoC8ZLMcOQIzRsjSoKKdumBtiyQ== X-Received: by 2002:a63:1953:0:b0:438:6e74:92e2 with SMTP id 19-20020a631953000000b004386e7492e2mr15594039pgz.150.1662962874712; Sun, 11 Sep 2022 23:07:54 -0700 (PDT) Received: from google.com ([240f:75:7537:3187:7b09:9fce:b16b:c111]) by smtp.gmail.com with ESMTPSA id f16-20020aa79d90000000b005403b8f4bacsm4361429pfq.137.2022.09.11.23.07.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 11 Sep 2022 23:07:53 -0700 (PDT) Date: Mon, 12 Sep 2022 15:07:49 +0900 From: Sergey Senozhatsky To: Brian Geffon , Minchan Kim Cc: Andrew Morton , Nitin Gupta , linux-kernel@vger.kernel.org, Suleiman Souhlal , Rom Lemarchand , linux-mm@kvack.org, Sergey Senozhatsky Subject: Re: [RESEND RFC] zram: Allow rw_page when page isn't written back. Message-ID: References: <20220908125037.1119114-1-bgeffon@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1662962875; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=heRnSh/ihPz3+Q+MxSXEW9Y8QcvUAW165V+3AmdWDkE=; b=NpUNycX4JBgBZl4uY/3hMT8+EO3klwF0BKCJAV//J980t3fzY8BgjqlLfS71QVb1tDlgCp +g/cM1DIYWjp/rtUwRwgeOYdNnex3yvt/qpSVr90ZsCbyUvWicuMwJMCydrrn7YS0FuyUz vgw3lgTKvP9mUEq2ahD7TkMAxECxBws= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=IotzQhJc; spf=pass (imf04.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.210.181 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1662962875; a=rsa-sha256; cv=none; b=J1PU/+48I67KjNF3QNKhF7v8bhE4FvbH4JaDkdl0rTS2YeMHtJUSadJ9hHu85t+ZEvs3kM 4/lv0Zpv4RuEyf7I73ces8bDJ/4k24eVHswzT87x96HhUYkvJhCaAob0NO6feX8rSgyhxB YjDRIOtQ9tTmfLI3d/9bqQ2AwvRoSWc= X-Rspam-User: Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=IotzQhJc; spf=pass (imf04.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.210.181 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org; dmarc=pass (policy=none) header.from=chromium.org X-Rspamd-Server: rspam06 X-Stat-Signature: 4s3wfqsase9x9k8uxedqyjwag8zmwc6b X-Rspamd-Queue-Id: BCA014008F X-HE-Tag: 1662962875-399927 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 (22/09/12 13:37), Sergey Senozhatsky wrote: > On (22/09/09 17:30), Sergey Senozhatsky wrote: > > > +++ b/drivers/block/zram/zram_drv.h > > > @@ -50,6 +50,7 @@ enum zram_pageflags { > > > ZRAM_UNDER_WB, /* page is under writeback */ > > > ZRAM_HUGE, /* Incompressible page */ > > > ZRAM_IDLE, /* not accessed page since last idle marking */ > > > + ZRAM_NO_WB, /* Do not allow page to be written back */ > > > > > > __NR_ZRAM_PAGEFLAGS, > > > }; > > > > Unrelated but somehow related. > > > > I wonder if it's time for us to introduce a dedicated, say u16, > > flags member to struct zram_table_entry. Unless my calculations > > are extremely wrong, we are about to run out of spare bits in > > zram_table_entry::flags on 32-bit systems. > > Looking at it more - I wonder why do we define ZRAM_FLAG_SHIFT > as 24? This is far more than maximum zram object size. Our max > size needs PAGE_SHIFT bits (which is normally 12 bits, can be up > to 16 (for 64k arm64 pages)). So we probably can start defining > ZRAM_FLAG_SHIFT as (PAGE_SHIFT + 1). > > Or am I missing something? So I think what happened was that flags used to be a u8 member of zram_table_entry, commit d2d5e762c8990 merged u16 size (which was too large for object size) and u8 flags and just kept 8 bits for flags (and somehow assumed 32-bit long? 32 - 8) We definitely can store size in PAGE_SHIFT bits and have some extra spare bits for zram pageflags. Would have been even nicer if we could change type of flags from unsigned long to unsigned int, but bit_lock requires "volatile unsigned long *" data type, so because of bit_lock our zram_table_entriy is 4 extra bytes in size. Which probably isn't too bad; having extra pageflag bits on 32-bit systems is good news.