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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 2032CEE498B for ; Fri, 18 Aug 2023 18:18:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=qQOqfVYmPREAuXHgHbNOGN7Gt4wWKCgMAbPiupHhVGg=; b=J09dlmg5cIHr3K tKTfROZ110ZZwJ6cW8OGg4+Hdsn2ObsG12E2AduRKrE5GZpC9+xCLE2cvwRAfXgRhBExSYJlyiTea bQrKWIZIfqPlxVT36BN1vU0HI4Eq8YRKTNeDnUKTb+wsiDJ8Qu+cQXOIDqFzBN96J7QRf36KDLxAG D3Op3ipDI5gFXm9tgA4qkuA1jkoByTrJxp2yeACiR8jN5B+4R3LJsuzvcgJ51h4OV/7fu0QJHsPJF ExDmmHFSps6smcVWBTF7RbdVSNZvh1mC2KM8jZm0ZvqSpaEg86ItC60Wtarne0Ut1gTdSosqk4bx1 ZnHZJscJY+TQqUqbBaKw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qX436-009rPS-2g; Fri, 18 Aug 2023 18:18:16 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qX434-009rOf-0h for linux-arm-kernel@lists.infradead.org; Fri, 18 Aug 2023 18:18:15 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id B1A7664F85; Fri, 18 Aug 2023 18:18:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1F7E7C433C8; Fri, 18 Aug 2023 18:18:08 +0000 (UTC) Date: Fri, 18 Aug 2023 19:18:06 +0100 From: Catalin Marinas To: Alexander Potapenko Cc: will@kernel.org, pcc@google.com, andreyknvl@gmail.com, andriy.shevchenko@linux.intel.com, linux@rasmusvillemoes.dk, yury.norov@gmail.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, eugenis@google.com, syednwaris@gmail.com, william.gray@linaro.org Subject: Re: [PATCH v4 5/5] arm64: mte: add compression support to mteswap.c Message-ID: References: <20230720173956.3674987-1-glider@google.com> <20230720173956.3674987-6-glider@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20230720173956.3674987-6-glider@google.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230818_111814_296104_412BFC5A X-CRM114-Status: GOOD ( 15.52 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Jul 20, 2023 at 07:39:56PM +0200, Alexander Potapenko wrote: > Soon after booting Android, tag compression saves ~2.5x memory previously > spent by mteswap.c on tag allocations. With the growing uptime, the > savings reach 20x and even more. This sounds like a marketing claim ;). The way I read your statement is that the memory used for tag storage is 2.5x less with your patches and that's great. It means a 2.5x compression on average. How does the compression get so much better to 20x with more uptime? The number of tag storage allocations should be proportional to the pages swapped out (not equal as not all would be mapped as PROT_MTE). So you can indeed have a lot more pages swapped out than available in RAM and the tag storage can take space but not sure which numbers you divided to get 20x. Anyway, it would be nice to see the full picture of what the savings relative to the total RAM is. Given that the swap in this instance is zram, you have an upper bound of how many pages it can store. I'm just trying to assess whether the complexity added here is worth it. Maybe not as good as the RLE algorithm here, I was wondering whether we could use zswap to save the tags together with the page. I looked some time ago at it seemed slightly easier for zswap than zram. Another option is to make the swap format more generic to support metadata storage. Yet another option is for the zram to flag that it can compress the metadata together with the data (no swap format change needed; when decompressing the page, it populates the tags as well). -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel