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 45A4AC0015E for ; Wed, 19 Jul 2023 21:06:54 +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=o/Xy8PpIpk+QeWuhPelSAPhpf5PVaTTtXOpRieYkypk=; b=PN4ca+LLj//BeW KBZquSjmt9UTUjSwGsq1bM94eAkolvCQrRlDG5yDQVN4rhkTW9cfvBZWhIeduvtKMoFyJ/s85U/3/ eW321HHTgbYRU0rZaUk5VitQTrZ32VdSlCvZc19rGt14mblKifWo0ZJ6UxAUYMozSWu74HwMhDyv2 XC1vBC/Byl9pT4aAYrnsdmOpp7K2mJAec6+NksyfARwdY6w/uRpL4znGs/iXSq5LdfvonoR0GIOjV QYAy5UBm1d5WqauvLuGuhUDqjwqaNr3EDR4Mv/8BEXluZVBGzoZVRnV29I0kuvt2n22fkzJOJFbJ7 OYloXmO9hZmYKPSoxB0Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qMENX-008vd9-0I; Wed, 19 Jul 2023 21:06:35 +0000 Received: from mail-pf1-x430.google.com ([2607:f8b0:4864:20::430]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qMENT-008vbz-1F for linux-arm-kernel@lists.infradead.org; Wed, 19 Jul 2023 21:06:33 +0000 Received: by mail-pf1-x430.google.com with SMTP id d2e1a72fcca58-666e6541c98so43712b3a.2 for ; Wed, 19 Jul 2023 14:06:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689800787; x=1690405587; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=AF9IOZ3UOTWW343eOS95NBVTfJzpdBE851mdqjeU/1Q=; b=Bxo5mueUwonj/5hHo73MbXlsPi5m031iP5IOMeodjpAZs7ibdbjR5Tr17Ie3TLI4xy AEUm8PHAq4t4g/qyrCNWivV2Od8EsAtoowpv+VMDKiZAuwG9rdFdmkutTVR5cQVEqz4d iK3R+hlk3OVKOwJ9n+DGjtpNaJfUjNo4h/QrOSL84P7Ege/4EC/alZ8NWwpk086IRGwH sqvnzmS3YYk1+PWPoOT4zv3hNH3V8v7lPnnDQeNl3P6JDLmCDvBqwnZKDmaPdzGwQWW0 vzH9fVmvlu60xeW3jIs3B44nJLofA9n/O3z8T+19fc61yk3J6VaX9CU9ft7TiStXOXcS R2VA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689800787; x=1690405587; 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 :message-id:reply-to; bh=AF9IOZ3UOTWW343eOS95NBVTfJzpdBE851mdqjeU/1Q=; b=DeVpsK6Y5IAgfp2wj0KhKTCtnYcJPbQSSyJYH14G+lF6q85oR0EcNjP7/ICJgbN/cX 8dPjlNZZRU1JeKcRr6uPCn2kBiiepYAQsVY1Oqsx+FTNXQ3oslWwlT5fgcAvxqGGbdZ9 dEomz1Dxu4zaFoqSSquWhhMqYaJbE+V2eWBgEHNnDPV6ZPlYX9II5BzXMAY4GheHCGCW KWWwlgBIBo2/VTQp59L4E+4AiVYY0SvX6FKKx+JYYZkC4shTgE1WyZs4QNV8dzAKhzaD 597E+h5JIyiMgorC7I1HiS7dY8Hnyhgo6WIdgu5Rn4En5V9C41HPMJgkh7cWNe60vNu3 yX9g== X-Gm-Message-State: ABy/qLbN+p+brvVZgzF809FWyDCJwoIFJrwxHe/osDFFlnXekZEAaHr5 r5D7zs+KlC3rCQQh8Ne0IfU= X-Google-Smtp-Source: APBJJlEwaAofEGdtnh1eMWsBvCcQK2w2qQxoBcziY8OHfpMopP/Cv8j2HH8Q2WOBJm6DCVE8xkNdbw== X-Received: by 2002:a05:6a20:321b:b0:12f:9e13:12b1 with SMTP id hl27-20020a056a20321b00b0012f9e1312b1mr651719pzc.15.1689800787332; Wed, 19 Jul 2023 14:06:27 -0700 (PDT) Received: from localhost ([216.228.127.130]) by smtp.gmail.com with ESMTPSA id c26-20020a63961a000000b0055adced9e13sm4065221pge.0.2023.07.19.14.06.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 Jul 2023 14:06:26 -0700 (PDT) Date: Wed, 19 Jul 2023 14:06:24 -0700 From: Yury Norov To: Alexander Potapenko Cc: catalin.marinas@arm.com, will@kernel.org, pcc@google.com, andreyknvl@gmail.com, andriy.shevchenko@linux.intel.com, linux@rasmusvillemoes.dk, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, eugenis@google.com, syednwaris@gmail.com, william.gray@linaro.org Subject: Re: [PATCH v3 3/5] arm64: mte: implement CONFIG_ARM64_MTE_COMP Message-ID: References: <20230717113709.328671-1-glider@google.com> <20230717113709.328671-4-glider@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230719_140631_432302_337FB827 X-CRM114-Status: GOOD ( 41.28 ) 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 Wed, Jul 19, 2023 at 04:00:14PM +0200, Alexander Potapenko wrote: > > > + * 4. For the inline case, the following values are stored in the 8-byte handle: > > > + * largest_idx : i4 > > > + * r_tags[0..5] : i4 x 6 > > > + * r_sizes[0..4] : i7 x 5 > > > + * (if N is less than 6, @r_tags and @r_sizes are padded up with zero values) > > > + * > > > + * Because @largest_idx is <= 5, bit 63 of the handle is always 0 (so it can > > > + * be stored in the Xarray), and bits 62..60 cannot all be 1, so it can be > > > + * distinguished from a kernel pointer. > > > > I honestly tried to understand... For example, what the > > 'r_sizes[0..4] : i7 x 5' > > means? An array of 5 elements, 17 bits each? But it's alone greater > > than size of pointer... Oh gosh... > > iN (note that it is a small i, not a 1) is LLVM notation for an N-bit > integer type. > There's no such thing in C syntax, and describing the data layout > using bitfields would be painful. > Would it help if I add a comment explaining that iN is an N-bit > integer? Or do you prefer something like > > r_sizes[0..4] : 5 x 7 bits > > ? Yes, that would help. > > > > Moreover, MTE tags are all 4-bits. > > > > It seems like text without pictures is above my mental abilities. Can you > > please illustrate it? For example, from the #4, I (hopefully correctly) > > realized that: > > > > Inline frame format: > > 0 60 62 63 > > +---------------------------------------------------------------------+ > I think it's more natural to number bits from 63 to 0 > > > | No idea what happens here | Lidx | X | > > +---------------------------------------------------------------------+ > > 63 : X : RAZ : Reserved for Xarray. > > 60-62 : Lidx : 0..5 : Largest element index. > > There's some mismatch now between this picture, where Lidx is i3, and > the implementation that treats it as an i4, merging bit 63 into it. > Maybe we can avoid this by not splitting off bit 63? > > > 6 : Reserved > > 7 : Invalid handler > > No, 7 means "treat this handle as an out-of-line one". It is still > valid, but instead of tag data it contains a pointer. So, it's invalid combination for _inline_ handler, right? Anyways, I'm waiting for an updated docs, so it will hopefully bring some light. > > > + > > > +/* Transform tag ranges back into tags. */ > > > +void ea0_ranges_to_tags(u8 *r_tags, short *r_sizes, int r_len, u8 *tags) > > > +{ > > > + int i, j, pos = 0; > > > + u8 prev; > > > + > > > + for (i = 0; i < r_len; i++) { > > > + for (j = 0; j < r_sizes[i]; j++) { > > > + if (pos % 2) > > > + tags[pos / 2] = (prev << 4) | r_tags[i]; > > > + else > > > + prev = r_tags[i]; > > > + pos++; This code flushes tags at every 2nd iteration. Is that true that there's always an even number of iterations, i.e. rsizes is always even, assuming r_len can be 1? If not, it's possible to loose a tag, consider rlen == 1 and rsizes[0] == 1. If yes, you can simplify: for (i = 0; i < r_len; i++) for (j = 0; j < r_sizes[i]; j++) tags[pos++] = (r_tags[i] << 4) | r_tags[i]; Anyways, in the test can you run all possible combinations? > > > + } > > > + } > > > +} > > > +EXPORT_SYMBOL_NS(ea0_ranges_to_tags, MTECOMP); > > > > Because I didn't understand the compressed frame format, not sure I > > can understand this logic... > Hope the above comments will help, if not - please let me know. > > > > + > > > +/* Translate @num_ranges into the allocation size needed to hold them. */ > > > +static int ea0_alloc_size(int num_ranges) > > > +{ > > > + if (num_ranges <= 6) > > > + return 8; > > > + if (num_ranges <= 11) > > > + return 16; > > > + if (num_ranges <= 23) > > > + return 32; > > > + if (num_ranges <= 46) > > > + return 64; > > > + return 128; > > > +} > > > + > > > +/* Translate allocation size into maximum number of ranges that it can hold. */ > > > +static int ea0_size_to_ranges(int size) > > > +{ > > > + switch (size) { > > > + case 8: > > > + return 6; > > > + case 16: > > > + return 11; > > > + case 32: > > > + return 23; > > > + case 64: > > > + return 46; > > > + default: > > > + return 0; > > > + } > > > +} > > > > I wonder if there's a math formula here? Can you explain where from > > those numbers come? > > I'll add a comment there. > Basically, for the inline case it is the biggest N such as 4 + 4*N + > 7*(N-1) <= 63 > > (not 64, because Xarray steals one bit from us) > > For the out-of-line case it is the biggest N such as 6+4*N + 7*(N-1) > <= array size in bits (128, 256, or 512). So it's: N <= (BIT_CAPACITY + NUM4 - NUM7) / (TAGSZ + SZ) Doesn't look like a rocket science... Why don't you code the formula instead of results? Are there any difficulties? Things may change. For example, in next spec they may bring 3- or 5-bit tags, and your compressor will crack loudly with hardcoded numbers. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel