Received: by 2002:a05:6358:7058:b0:131:369:b2a3 with SMTP id 24csp10773963rwp; Fri, 21 Jul 2023 04:59:30 -0700 (PDT) X-Google-Smtp-Source: APBJJlFYC9jhkT5dbbnfDltrg74ZBKIT5/w/6VlbHHGFVJr/V9P9uwlU/gsO/OaneuLDig5pUzic X-Received: by 2002:a05:6512:10ca:b0:4f1:3d7d:409e with SMTP id k10-20020a05651210ca00b004f13d7d409emr1405467lfg.0.1689940769745; Fri, 21 Jul 2023 04:59:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1689940769; cv=none; d=google.com; s=arc-20160816; b=jJrb9hTyEmdtvG517MUztQ6SMw8ACCvjNSLJ5gro2t3mE+iUI8WP0EcmamNfj5JYjC VJveQX4iwMpCRLxSeggu3jyjCgGcTQwpF5cwvtVK3BRl8s8da8oDa7MGuJYYnU5Oj62P 81J3naKRfQVF+PDE9eTo1lgeUtC2EZ1KV2RSZZDnkqpmdgkvsEhokBzr5OG7mkYWdm1x 7fFPP8O94NsbhYqk89f0FoBZBlJwtSow7AGrje6Uo4JA26tkNxGqYUlnKl9GV3Oi4agV l3yKc/oYlyL5S+MbXchfwceL4gBbJRLcBaNLonhDN3+3L9PGJ6TnWcLe2oWEBEfHTVQW /9RQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:organization:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=Z3v8dL/i8Di6ZEjKVTFO0LRIbJkD2bCyn+oXAIdeHYI=; fh=nkfDF3O4gP7Foz5L+L4LYKYHPovB+ZadJh7iDsaP9gg=; b=mZr/kKSQqEJarsTFb2b2golwlQ5IDn6P8VQ7RIttuz1CPyzXEAS0QtVPFGzU7beqQa akS+2B4IstbeLOWV6qhYBwE2PgYeoIO3Cf0E5O4JyhrY9M22ycBMsRNs6CxvS1OytIaN jGNVjaziqkiI+g2Sv7s117DV5NRPkg21+G2U4tfKc4aVA7GAXLXdUo31t5pl5p/aFBBw U3/Nfbrx1DuTuMF4urSycuzPAqS0cu7EZEzDE5TN7YCoykW7374VC5M6WClvd6xVsHVM tFsdgNETO0rfZz6HnJcMsCQ2G8m3pjDFUy/xlghYpOCkezQJeEPkT/Vy1yjkqq0pnJwZ 9P5g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=gL88cQoe; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id cw11-20020a170906c78b00b00991f9f3b83bsi2124453ejb.228.2023.07.21.04.59.05; Fri, 21 Jul 2023 04:59:29 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=gL88cQoe; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229934AbjGULWO (ORCPT + 99 others); Fri, 21 Jul 2023 07:22:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36520 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229896AbjGULWM (ORCPT ); Fri, 21 Jul 2023 07:22:12 -0400 Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1FA601996 for ; Fri, 21 Jul 2023 04:22:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1689938530; x=1721474530; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=57KU9BS+4WtXtGFaL6wZCWV3ud+hpdZFulKGMvMZrP8=; b=gL88cQoecLwSmwrCuQ7mE4asKvCWtfWcyqDSoq4umvrJc9M6f2JUygMO WjReyVtZybeBhThVFEowQ08TCOX5vcn6RtpILjvyTnt3CMeRw1ZjzCA9c 4zW+M7K2O5gYVpjjdZAJKCtoacgJGA7hK2SLuKerq2kTLxI8T5B8xXA9P UtsMTZ/L7qin0NsKHpcvqQLzDGcojTfbu/dciEmmKxC8SkHUou5Mzmgq/ ueS1Ug+8VIjwlsLgH2t8+KN+JSw4Lk3ZimoxLfo4VZI5ONggHmARLQbpi NmzUx5Gwj9EFJ6h0Vaqe7Rj7JUB1JH0OAu8duN1hScnonUEdJVLtGURi5 w==; X-IronPort-AV: E=McAfee;i="6600,9927,10777"; a="433229016" X-IronPort-AV: E=Sophos;i="6.01,220,1684825200"; d="scan'208";a="433229016" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Jul 2023 04:22:09 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10777"; a="971411749" X-IronPort-AV: E=Sophos;i="6.01,220,1684825200"; d="scan'208";a="971411749" Received: from smile.fi.intel.com ([10.237.72.54]) by fmsmga006.fm.intel.com with ESMTP; 21 Jul 2023 04:22:07 -0700 Received: from andy by smile.fi.intel.com with local (Exim 4.96) (envelope-from ) id 1qMoCz-001tP1-1g; Fri, 21 Jul 2023 14:22:05 +0300 Date: Fri, 21 Jul 2023 14:22:05 +0300 From: Andy Shevchenko To: Alexander Potapenko Cc: catalin.marinas@arm.com, will@kernel.org, pcc@google.com, andreyknvl@gmail.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 3/5] arm64: mte: implement CONFIG_ARM64_MTE_COMP Message-ID: References: <20230720173956.3674987-1-glider@google.com> <20230720173956.3674987-4-glider@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230720173956.3674987-4-glider@google.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_NONE,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 20, 2023 at 07:39:54PM +0200, Alexander Potapenko wrote: > The config implements the algorithm compressing memory tags for ARM MTE > during swapping. > > The algorithm is based on RLE and specifically targets 128-byte buffers > of tags corresponding to a single page. In the common case a buffer > can be compressed into 63 bits, making it possible to store it without > additional memory allocation. ... > +Programming Interface > +===================== > + > + .. kernel-doc:: arch/arm64/mm/mtecomp.c :export: > + Is it dangling trailing blank line? Drop it. ... > +#include > +#include This is guaranteed to be included by bitmap.h. > +#include > +#include > +#include > +#include > +#include > +#include ... > +/* > + * Sizes of compressed values. These depend on MTE_TAG_SIZE and of the > + * MTE_GRANULES_PER_PAGE. > + */ ... > + u8 prev_tag = tags[0] / 16; /* First tag in the array. */ > + unsigned int cur_idx = 0, i, j; > + u8 cur_tag; > + out_tags[0] = prev_tag; out_tags[cur_idx] ? > + for (i = 0; i < MTE_PAGE_TAG_STORAGE; i++) { > + for (j = 0; j < 2; j++) { > + cur_tag = j ? (tags[i] % 16) : (tags[i] / 16); > + if (cur_tag == prev_tag) { > + out_sizes[cur_idx]++; > + } else { > + cur_idx++; > + prev_tag = cur_tag; > + out_tags[cur_idx] = prev_tag; > + out_sizes[cur_idx] = 1; Looking more at this I think there is still a room for improvement. I can't come up right now with a proposal (lunch time :-), but I would look into do { ... } while (i < MTE_...); approach. > + } > + } > + } ... > +static size_t mte_size_to_ranges(size_t size) > +{ > + size_t largest_bits; > + size_t ret = 0; Redundant assignment. Please, check again all of them. > + > + largest_bits = (size == 8) ? MTE_BITS_PER_LARGEST_IDX_INLINE : > + MTE_BITS_PER_LARGEST_IDX; > + ret = (size * 8 + MTE_BITS_PER_SIZE - largest_bits) / Hmm... I thought that we moved BYTES_TO_BITS() to the generic header... Okay, never mind. > + (MTE_BITS_PER_TAG + MTE_BITS_PER_SIZE); > + return ret; return (...) / ...; > +} ... > +static size_t mte_alloc_size(unsigned int num_ranges) > +{ > + size_t sizes[4] = { 8, 16, 32, 64 }; Hooray! And now it's not needed anymore... > + unsigned int i; > + > + for (i = 0; i < ARRAY_SIZE(sizes); i++) { ...as sizes[i] is equivalent of (8 << i). > + if (num_ranges <= mte_size_to_ranges(sizes[i])) > + return sizes[i]; > + } > + return 128; > +} > +} ... > +/** > + * mte_compress() - compress the given tag array. > + * @tags: 128-byte array to read the tags from. > + * > + * Compresses the tags and returns a 64-bit opaque handle pointing to the > + * tag storage. May allocate memory, which is freed by @mte_release_handle(). + blank line here. > + * Returns: 64-bit tag storage handle. > + */ ... > + /* > + * mte_compress_to_buf() only initializes the bits that mte_decompress() > + * will read. But when the tags are stored in the handle itself, it must > + * have all its bits initialized. > + */ > + unsigned long result = 0; // Actually it's interesting how it's supposed to work on 32-bit // builds... DECLARE_BITMAP(result, BITS_PER_LONG); and then bitmap_zero(); ? ... > +static unsigned long mte_bitmap_read(const unsigned long *bitmap, > + unsigned long *pos, unsigned long bits) > +{ > + unsigned long result; > + > + result = bitmap_read(bitmap, *pos, bits); > + *pos += bits; > + return result; unsigned long start = *pos; *pos += bits; return bitmap_read(bitmap, start, bits); > +} ... > + unsigned short r_sizes[46], sum = 0; See below. ... It's cleaner and more robust to have sum = 0; here. > + for (i = 0; i < max_ranges; i++) { > + if (i == largest_idx) > + continue; > + r_sizes[i] = > + mte_bitmap_read(bitmap, &bit_pos, MTE_BITS_PER_SIZE); > + if (!r_sizes[i]) { > + max_ranges = i; > + break; > + } > + sum += r_sizes[i]; > + } > + if (sum >= 256) > + return false; -- With Best Regards, Andy Shevchenko