From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 64D572727E6 for ; Fri, 12 Sep 2025 19:18:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=216.40.44.16 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757704693; cv=none; b=RN6Pgb6pgfw1fg0AanSGEv+Llb1QUIXw1cai7Ck3MGdxfoiUkO4K38hlBerSrJh7lNU7ahgLT7J38fN06LePZMPtjytAYlCXUGvOoZlTjId8GiENI13bezEA4N4I3ibb5M+Qp+pd2jPxbywYy6NZTsCROMhELplfLDpj4KmO4Vk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757704693; c=relaxed/simple; bh=rki9E2vxizJ4o+J1J6U+5bgJujxfr4YhuZ901v0I7mQ=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=BlibmWY60WkUw85Wks91TGXJv11wmR/1OHu498n+/tO5jCjooQB0xoqFoGVYxNrN1XoKhihLQQ3t7OI0VQTK6d0xLRG4046inVh9VHrh/WNLVwKl/nBoNcbi/KxLKlK4mDu5oJ13WqIC57ElQGUrjMcuIzrsTieZ2i273Yoge7Q= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=goodmis.org; spf=pass smtp.mailfrom=goodmis.org; arc=none smtp.client-ip=216.40.44.16 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=goodmis.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=goodmis.org Received: from omf06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 982421A08F9; Fri, 12 Sep 2025 19:18:02 +0000 (UTC) Received: from [HIDDEN] (Authenticated sender: rostedt@goodmis.org) by omf06.hostedemail.com (Postfix) with ESMTPA id 8F2D920014; Fri, 12 Sep 2025 19:18:00 +0000 (UTC) Date: Fri, 12 Sep 2025 15:18:55 -0400 From: Steven Rostedt To: Indu Bhagat Cc: Jens Remus , Sterling Augustine , Pavel Labath , Andrii Nakryiko , Josh Poimboeuf , Serhei Makarov , Binutils , "linux-toolchains@vger.kernel.org" Subject: Re: Unaligned access trade-offs for SFrame FRE layout Message-ID: <20250912151855.3af8c2ab@gandalf.local.home> In-Reply-To: References: X-Mailer: Claws Mail 3.20.0git84 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-toolchains@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Stat-Signature: qjmaca448au8cjjzpnaokca6up7hf3h7 X-Rspamd-Server: rspamout05 X-Rspamd-Queue-Id: 8F2D920014 X-Session-Marker: 726F737465647440676F6F646D69732E6F7267 X-Session-ID: U2FsdGVkX1/TbLv1I2+azUdrtcjqKcumr0MbxPby7Z4= X-HE-Tag: 1757704680-636749 X-HE-Meta: U2FsdGVkX1+64rRVsx8Y4XCCzlIaZTWmIIvIQBhTGNu53Oa1SNFcbRxt4WYkvDvzGv5c8IGHbQprHUGO254UnCLT+w15gyGyw9XHkGraIWIEAgUIXGAcftSe0EAljOufNCaL4CiLxxqqo0kQ7kT4UZqnFfhy7ckV7jYBA7QS1w8y4JbTh0j4z8El+pZBXkRTAdf6EPPwUbA5VdsFOgjzyykET3985CU1UFIJpH1Xc1qvbeGuWiqiYAbcPBiYKCmcOL1s8DVGX6pnUQg7n6gwlrPycxBo4e63+2BWKV4axk7H4YKrWD02s4dmnepokSgdpGIGbMw7NKhpqdVO5f4A8XEbuGSX7J3ShCUQYTjTFWJSeTPirFfbiuZj6VMR4LpACMtiBiQEyAaZatgL7BZnUg== On Fri, 12 Sep 2025 10:34:42 -0700 Indu Bhagat wrote: > TL;DR: Thinking and experimenting a bit on the possible approaches for > avoiding unaligned accesses in the SFrame FRE layout (in SFrame V3), I > am not convinced that avoiding unaligned accesses for performance is > worth it. IMO, forsaking compactness for avoiding unaligned accesses is > not a good trade off for SFrame. > > Problem Statement > On architectures such as x86_64, AArch64, and s390x, unaligned memory > accesses are handled transparently by the hardware but incur a > performance penalty. The objective of this analysis is to evaluate if > these unaligned accesses can be eliminated from the SFrame FRE layout > and if doing so provides a net performance benefit. I guess the question is really, is it that big of a performance hit? I know some others were worried about the performance, but we should look at measurements too. Is it going to be a big enough issue in the stack unwinding code to even notice? > > The central challenge is that any alternative must demonstrate a clear > performance improvement while avoiding significant size overhead. > Introducing "bloat" to the format to solve a potential performance issue > is a poor trade-off. Correct. I would like to see performance numbers before we invest too much time in this. > > Source of unaligned accesses in SFrame FRE > - (#1) Access to the SFrame FRE start address (sfre_start_address) > - (#2) Access to the SFrame FRE stack offsets, This is varlen data > tailing SFrame FRE top-level members (sfre_start_address and FRE info), > usually interpreted as stack offsets) BTW, we should also look at how often are there unaligned accesses? All the time? or just a percentage of time? If it is a percentage, what is that percentage? > > (Note that in the SFrame specification, SFrame Header, and SFrame FDE > (function descriptor entry) have aligned accesses.) > > Updated notes on the various approaches and respective evaluation notes > on the wiki page: > https://sourceware.org/binutils/wiki/sframe/sframev3todo#Avoid_unaligned_accesses > > Summary of Approaches and Analysis/Notes > Unaligned accesses may mean lower performance, but the alternative we > pick must at least provide better performance. It is also important > that the chosen approach does not add bloat to the format. Avoiding > unaligned accesses at the expense of bloating up the format is not a > good idea IMO. > > Approach 1a: Bucketed members > Pros: Negligible bloat. > Cons: 1. Writing out the FRE data is somewhat more involved. Affects > assemblers, linkers. 2. For the common case though, accessing stack > offsets now needs more memory accesses per FRE. This approach will not > bring clear performance benefits; the additional complexity in SFrame > readers and writers is not justified then either. Right. If this causes more cache misses or worse, more page faults, to save from an unaligned access, I don't think it's worth it. > > Approach 1b: Bucketed members with Index > Cons: Significant bloat (~30%). I personally believe 30% is too much overhead. > > Approach 2: De-duplicated "stack offsets" > Pros: Will help reduce the size of SFrame sections. > Cons: 1. SFrame FRE layout is designed to be flexible so that it can > serve needs of new ABIs: The varlen data is interpreted as stack > offsets on x86_64, and AArch64, but may not be the case for other ABIs. > De-duplicating non-structured data is not meaningful. 2. Writing out the > FRE data is quite more involved, increasing the complexity in Toolchain. I don't know enough to comment about the above. > > Approach 3: Good old basic padding > Cons: Significant bloat (~22%). Performance win arguable as well. I think 22% is also too much. > > IMO, none of these approaches provide viable way to move forward. The > proposed methods either fail to deliver the desired clear performance > gain or introduce a significant size penalty or complexity, which is an > unacceptable trade-off. > > Would like to gather inputs from the interested folks on this. Please > take a look and chime in. Other ideas welcome. As stated above, I'd like to know how much of a performance benefit this is. It may not be worth it. I wasn't one of the people who brought up unaligned accesses. I'd like to hear from them to get their input. -- Steve